Re: ScrollDC fixes.

[Alexandre Julliard]

Rein Klazes  writes:
> -
>    if(( size = GetRegionData( SrcRgn, 0, NULL )) &&
> -
>            (rdata = HeapAlloc( GetProcessHeap(), 0, size ))) {
> -
>        GetRegionData( SrcRgn, size, rdata );
> -
>        /* the rectangles in the region data are ordered top-to-bottom
> -
>         * So if the scrolling is downward, traverse the array backwards
> -
>         * to avoid touching pixels that have yet to be scrolled  */
> -
>        /* FIXME: implement something similar for left-to-right
> -
>         * scrolling. */
> -
>        if( dydev < 0 ) {
> -
>            step = 1;
> -
>            rect = (RECT *)rdata->Buffer;
> -
>        } else {
> -
>            step = -1;
> -
>            rect = ((RECT *)rdata->Buffer) + rdata->rdh.nCount - 1;
> -
>        }
> -
>        for( i = 0; i < rdata->rdh.nCount; i++, rect += step) {
> -
>            DPtoLP(hdc, (LPPOINT)rect, 2);
> -
>            TRACE("Bit blitting %s to %ld,%ld\n", wine_dbgstr_rect(rect),
> -
>                    rect->left + dx, rect->top + dy);
> -
>            BitBlt( hdc, rect->left + dx, rect->top + dy,
> -
>                        rect->right - rect->left, rect->bottom -rect->top,
> -
>                        hdc, rect->left, rect->top, SRCCOPY);
> -
>        }

You really shouldn't need to scroll the region rectangle by
rectangle. Selecting the proper clip region and then copying the whole
area should have the same effect.
>                      {
>                          XEvent event;
>
> -
>                        XWindowEvent( gdi_display, physDev->drawable, ~0, &event );
> -
>                        if (event.type == NoExpose) break;
> -
>                        if( !XCheckWindowEvent( gdi_display, physDev->drawable, ~0, &event ))
> -
>                            break;
> -
>                        if (event.type == NoExpose) continue;

You can't use XCheckWindowEvent, you need to wait for the events that
haven't arrived yet.

ScrollDC fixes.

[Rein Klazes]

On 07 Mar 2005 19:44:07 +0100, you wrote:
> > -
> >        for( i = 0; i < rdata->rdh.nCount; i++, rect += step) {
> > -
> >            DPtoLP(hdc, (LPPOINT)rect, 2);
> > -
> >            TRACE("Bit blitting %s to %ld,%ld\n", wine_dbgstr_rect(rect),
> > -
> >                    rect->left + dx, rect->top + dy);
> > -
> >            BitBlt( hdc, rect->left + dx, rect->top + dy,
> > -
> >                        rect->right - rect->left, rect->bottom -rect->top,
> > -
> >                        hdc, rect->left, rect->top, SRCCOPY);
> > -
> >        }
>
> You really shouldn't need to scroll the region rectangle by
> rectangle. Selecting the proper clip region and then copying the whole
> area should have the same effect.

Hmm, this is about pixels that are copied from the outside of the
visible region to the inside (that area will be invalidated and
repainted if called through ScrollWindowEx, but with noticeable
flickering and there might be direct uses of ScrollDC with worse
effects).
Since the visible region did not work, I did not try adding an extra
clip region. Indeed, adding: "SelectClipRgn( hdc, visrgn);" does not
help at all.
Can the real bug perhaps be in BitBlt?
> >                      {
> >                          XEvent event;
> >
> > -
> >                        XWindowEvent( gdi_display, physDev->drawable, ~0, &event );
> > -
> >                        if (event.type == NoExpose) break;
> > -
> >                        if( !XCheckWindowEvent( gdi_display, physDev->drawable, ~0, &event ))
> > -
> >                            break;
> > -
> >                        if (event.type == NoExpose) continue;
>
> You can't use XCheckWindowEvent, you need to wait for the events that
> haven't arrived yet.

That is what the XFlush() is for, and it seems to work quite nicely
(after BitBlitting regions of over 50 separate rectangles). Without it,
it is a mess indeed.

Rein.

ScrollDC fixes.

[Alexandre Julliard]

Rein Klazes  writes:
> Hmm, this is about pixels that are copied from the outside of the
> visible region to the inside (that area will be invalidated and
> repainted if called through ScrollWindowEx, but with noticeable
> flickering and there might be direct uses of ScrollDC with worse
> effects).
> Since the visible region did not work, I did not try adding an extra
> clip region. Indeed, adding: "SelectClipRgn( hdc, visrgn);" does not
> help at all.
> Can the real bug perhaps be in BitBlt?

I doubt that, I don't see how copying the single rectangle of the
bounding box of the region would be different from copying every
individual rectangle.
> That is what the XFlush() is for, and it seems to work quite nicely
> (after BitBlitting regions of over 50 separate rectangles). Without it,
> it is a mess indeed.

The XFlush is just hiding the bug, try it on a low latency link and
you'll see. You'd need an XSync but that would just cause an extra
round trip for no good reason.

ScrollDC fixes.

[Rein Klazes]

On Tue, 08 Mar 2005 09:53:07 +0100, I wrote:
> Hmm, this is about pixels that are copied from the outside of the
> visible region to the inside (that area will be invalidated and
> repainted if called through ScrollWindowEx, but with noticeable
> flickering and there might be direct uses of ScrollDC with worse
> effects).
> Since the visible region did not work, I did not try adding an extra
> clip region. Indeed, adding: "SelectClipRgn( hdc, visrgn);" does not
> help at all.
> Can the real bug perhaps be in BitBlt?

Don't mind, I see what you mean. I have to subtract the destination
region of those pixels and then clip.

Rein.