discuss-gnustep
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GORM and NSCollectionView


From: Alessandro Sangiuliano
Subject: Re: GORM and NSCollectionView
Date: Sun, 22 Mar 2015 13:54:27 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0

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)






reply via email to

[Prev in Thread] Current Thread [Next in Thread]