Re: GORM and NSCollectionView

[Alessandro Sangiuliano]

Thank you for the suggestions. I just started to look at the code you 
mentioned.

The problem is that I also have to deal with a lot of X11 documentation.


Il 21/03/2015 19:39, Matt Rice ha scritto:
> 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)