Re: GORM and NSCollectionView

[Matt Rice]

On Sat, Mar 21, 2015 at 6:40 AM, Alessandro Sangiuliano
<alex22_7@hotmail.com> wrote:
> Il 20/03/2015 12:13, Alessandro Sangiuliano ha scritto:
>
>> Il 19/03/2015 22:19, Fred Kiefer ha scritto:
>>>
>>> Am 17.03.2015 um 14:17 schrieb Alessandro Sangiuliano:
>>>>
>>>> Il 17/03/2015 09:53, Riccardo Mottola ha scritto:
>>>>>
>>>>> Fred Kiefer wrote:
>>>>>>
>>>>>> I just tried with 31 students and the flickering is horrible, but it
>>>>>> stops as soon as I let go of the window. Which Window manager are you
>>>>>> using?
>>>>>
>>>>> I am running windowmaker and I must say that flickering during resize
>>>>> is quite bad for may windows and different applications. This both
>>>>> with the art backend as with the cairo backend.
>>>>>
>>>> I'm using Window Maker too.
>>>> Did you tried with more than 31? For e.g. 100? The flickering will
>>>> become just worse.
>>>> However the flickering is happening with whatever window manager you wil
>>>> use. I also tried to make gnustep to handle windows but I don't remember
>>>> if it happens, I'll try as soon as I can again and report back (but I
>>>> strongly think that was yes, it was flickering too).
>>>>
>>>> Actually I'm on a train, can you suggest me what are the files that are
>>>> handling double buffering (X11 relative) in -back?
>>>
>>> Even with a lot more subelements the flickering stops as soon as I
>>> finish the resize. But with plenty of students I sometimes end up with a
>>> corrupted display that only gets fixed when I scroll in the window.
>>
>>
>>
>> The same is happening here for the corrupted display... I just was testing
>> and thinking on how to report back this problem. I mean, when I add  a lot
>> of students, then resize the window , subelements overlaps on other
>> subelements, corrupting the view, then scrolling, fix the corrupted view. I
>> think you was talking about this behavior right?
>>
>> 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)