On Fri, Jul 6, 2012 at 9:45 AM, Brian Hinz wrote:
> On Wed, Jul 4, 2012 at 3:35 AM, Pierre Ossman wrote:
>
>> On Tue, 3 Jul 2012 16:42:11 -0400
>> Brian Hinz wrote:
>>
>>
>> > Hi Pierre,
>> >
>> > I'm not sure if this means anything to you, but I found that if I set
>> > 'AlwaysSetDeferUpdateTimer=1' then outline boxes are partially drawn and
>> > damaged regions are sometimes partially redrawn. The location and
>> extent
>> > to which the lines are drawn is seemingly random, but it's never
>> complete
>> > (except when a screen refresh is requested). Also, the value of
>> > 'DeferUpdate' does not seem to make any difference. Any thoughts?
>> >
>>
>> Nothing obvious comes to mind, no. I'm not sure what your test case is,
>> but if you're dragging windows around then having a deferred update
>> might work as a workaround for the problem. The server would in that
>> case really be registering multiple changes of the working parts of the
>> border, which then happen to overlap the areas that are overlooked.
>>
>> One idea is to ask on the X list for suggestions on where in the Xorg
>> code that the server does the implicit rendering. That might make it
>> easier to trace where we should have hooks.
>>
>
>
> I stumbled onto this bug report for Xquartz:
>
> http://xquartz.macosforge.org/trac/ticket/290
>
> The ticket is marked as closed but if you follow the thread, the Xorg bug
> is re-opened:
>
> https://bugs.freedesktop.org/show_bug.cgi?id=26124
>
> It certainly appears to be the same or very similar problem.
>
> After applying the patches from
> http://cgit.freedesktop.org/xorg/xserver/commit/?id=2d6a8f668342a5190cdf43b5d385f592d10f5900
> there
> does seem to be some improvement. Damaged regions are generally repaired
> correctly if the window is dragged around or over top of another area
> without borders (even if that area is not obscured by the window), but the
> initial drawing is not performed and if a window is redrawn (or shaded up &
> down) the borders are cleared.
>
> I've appended a comment to the xorg bug as well.
>
> -brian
>
I've been trying to trace back the source of the PolyFillRects and they
definitely come from miHandleValidateExposures in mi/miwindow.c ->
miPaintWindow in mi/miexpose.c and then the PolyFillRect hook should be
called from miPaintWindow. At the point where miPaintWindow should be
calling the hook function, the rectangles are correct, but then the
xRectangle that gets evaluated in vncHooksPolyFillRect is not the same.
Sometimes vncHooksPolyFillRect is not even called after miPaintWindow at
all... I'm utterly confused as to how this could be happening, any chance
someone can take a peek and see if you can make some sense of it?
Thanks,
-brian
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Tigervnc-devel mailing list
Tigervnc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
