Re: GORM and NSCollectionView

[Fred Kiefer]

Am 21.03.2015 um 19:39 schrieb Matt Rice:
> On Sat, Mar 21, 2015 at 6:40 AM, Alessandro Sangiuliano
>>> The flickering also stops when I finish the resize; however the flickering
>>> during the resize should never happen, as it doesn't happen on other UI
>>> toolkit. I'd like to see and understand, as starting point, where the
>>> problem occurs.
>>>
>>> I have no Windows/GNUstep env, to try if the flickering happens there too.
> 
> fwiw, i've seen flickering on resize in something or other (non-gnustep)
> caused by the XExposeEvent's count field being zero when resizing even
> though a multitude of expose event's exist in the event queue
> 
> the relevent code from XGServerEvent.c being here:
> 
> 1068 #if 1
> 1069 // ignore backing if sub-window
> 1070 [self _addExposedRectangle: rectangle : cWin->number : isSubWindow];
> 1071
> 1072 if (xEvent.xexpose.count == 0)
> 1073 [self _processExposedRectangles: cWin->number];
> 1074 #else
> 
> IIRC it helped when receiving an event to loop until one of the XCheck
> variants of XWindowEvent() doing the equivalent of the
> _addExposedRectangle: call, until it returned false.
> 
> note the documentation for XExposeEvent:
> The count member is set to the number of Expose events that are to follow.
>        If count is zero, no more Expose events follow for this window.
> However, if count is nonzero, at least that number
>        of Expose events (and possibly more) follow for this window.
> 
> 
> the curious thing to note is the '(and possibly more)', but that this
> is stated only in the 'however if count is nonzero', for some reason I
> recall that this was also the case sometimes when the count was
> zero...
> 
> it'd be worthwhile to add some logs here of both the events count and
> some XPeekIfEvent magic to determine the actual number of expose
> events, this is kind of a pain since there is no variant combining the
> XCheck and XPeek behaviors, maybe using globals in the predicate of an
> XCheckIfEvent and always returning False I suppose......
> 
> Anyhow this made our event handling code rather messy because the
> events were being pulled off the event queue in more places than a
> single loop like gnustep's (ignoring the XMotionNotify compression)

I don't think this issue is about getting multiple expose events. I have
tried to track down the issue for quite a few hours now and have only
some progress. Lets summon up to allow others to build on that:

- The flickering consists of different parts. One is black, another is
white and the third is the real window but sometimes with an offset.
(not sure about the last bit)

- I could track down the black drawing, this comes from
_addExposedRectangle::: which draws directly after a resize of the
window without the graphic context for the window being set up properly.
This means that it copies over invalid bits form the backing store into
the window.
This issue has already been fixed by Richard on the 24th of September
2006 when he added the "#else" branch to the code Matt cited above. But
on the same day Richard did disable this new code again by changing "#if
0" into "#if 1".
I don't remember anything of this and didn't find it in the mailing
lists. Richard do you have any recollection? Otherwise I would switch
again and let people test that "new" code of yours.

- As for the white part I also found the source. The most likely reason
was that we tell X11 somewhere to fill the window with the
background_pixel and we never use setbackgroundcolor:: to change this
value. I made a quick check and changed the default value in -window::::
from white into black and really did get a black flickering.
I then experimented with the setbackgroundcolor:: method, but that never
gets called and it wouldn't work correctly anyway if we just change the
background colour of the content view, not the one of the window.
The actual setting of the window background was in the XCreateWindow()
call and I just removed the CWBackPixel there. This might worsen things
for the xlib backend, but we can look into that after somebody complains.

Now the flickering is gone for me. I still have the other problem of
corrupted subview display after extensive resize, but I wont be looking
into that today. I just will commit my changes and you all should try to
test them with different conditions, maybe even the OpenGL?

Fred