This is a MIME GnuPG-signed message. If you see this text, it means that
your E-mail or Usenet software does not support MIME signed messages.
The Internet standard for MIME PGP messages, RFC 2015, was published in 1996. To open this message correctly you will need to install E-mail or Usenet software that supports modern Internet standards.

https://www.x.org/releases/X11R7.7/doc/xproto/x11protocol.html#requests:CopyArea
does not specify what happens when src-drawable and dst-drawable are the
same, and the source rectangle overlaps with the destination rectangle.

I would like to efficiently scroll a rectangle within my drawable by a specified amount. That is: shift all the pixels in the rectangle in the horizontal and/or vertical direction by some specified amount. Afterwards
there will be some exposed part of the rectangle that I'll proceed and
render appropriately, but for now I'm trying to determine what is the most efficient way to scroll the rectangle.

Say, for example, I need to take a 100x100 pixel rectangle whose upper-
left coordinates are (0, 0) and scroll it up by 10 pixels. Expressed purely
in CopyArea's terms this would be equivalent to:

src-drawable, dst-drawable: DRAWABLE (same drawable for both)
gc: CONTEXT
src-x: 0
src-y: 10
width: 100
height: 90
dst-x: 0
dst-y: 0

But, CopyArea does not specify how an overlapping CopyArea, like that, gets handled. This would have the expected result if the server copies the rectangle, row by row, from top to bottom; but not bottom to top.

I see only two possible ways to use CopyArea in this fashion:

- use a sequence of CopyArea calls, breaking up the entire rectangle into smaller non-overlapping CopyAreas. This seems to be rather inefficient if
the scrolling distance is very small, since this will translate into many CopyArea calls.

- use two CopyAreas calls, a CopyArea into a separate pixmap, then copy this back into the original drawable, into the destination rectangle. This would then require a pixmap to be as big as the rectangle getting scrolled, and be wasteful if the rectangle is big.

So, there is no preferred approach for scrolling rectangles, that I can see.

-----BEGIN PGP SIGNATURE-----

iQIcBAABAgAGBQJaf7IJAAoJEGs6Yr4nnb8lCy4P/2RQTN1yQALf1G0CvpxGw2H+ fiekj+h+URQ9wZ4bLX8Ak0WuaNpPRDOuhIh5dzrZYEDuEICCtoJtwyvcaUQAC/2V 79LyveOh/Z+ARFlKKQGw083BfY9Uc1G+c1fPEq0OvE7A+ZG49129ZfMDVHvB9V3a hEk45juYp1YjuULjn9CAoiFTJdlvqsc7gZAtQkluXtoE9tJcK3qTA1LqHCEEfN0N zhkB0HJc00yUV7c24Utt+5qQS0riXJh6wN8c4mfPhHaR0N66PBlu/0rLQGcHvSql Ri7sIaZ9Qe9LzQ5g9KxciLreytTlBIGhqbc6zTHD03zciOpL6gNdNE80pvyfgQB6 N/K4wpD5Um570oP/fVn5opQPH+h3uLVKBYb7kPH35JRC1fwBy5X9EmnGlKxIohRe /GR5DA5kUQAWP1gN6POCiSONnob/MzVcjnAgTBxvCfJkMsjuJeWncmWLgoCbAUrB JiXcLjUwUbWsZdeZDklPaEqMr0MDIlt3QIJmGsX+kYUghcPDfr88Bl1DlensWetB GwNwbnaaRH+TMiDJWvPpsTuCknPh2Vs7nwl2r82GS4f552rHUGMEigpq2dDPlPyC mGMk6IG0i8HW8ww4iH+whR1FbeZCGRbhNL4ZkDeozlEbiHXMd/KIgR32gjJDKftg quolp/n2J27+zc+mCfgd
=sVIc
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Sam <sam@email-scan.com> writes:

https://www.x.org/releases/X11R7.7/doc/xproto/x11protocol.html#requests:CopyArea
does not specify what happens when src-drawable and dst-drawable are
the same, and the source rectangle overlaps with the destination
rectangle.

I would like to efficiently scroll a rectangle within my drawable by a specified amount. That is: shift all the pixels in the rectangle in
the horizontal and/or vertical direction by some specified
amount. Afterwards there will be some exposed part of the rectangle
that I'll proceed and render appropriately, but for now I'm trying to determine what is the most efficient way to scroll the rectangle.

In any of X11R{5,6,7}, I've been able to use XCopyArea to scroll
overlapping areas up, down, right, left, or obliquely just fine. I
suspect XCopyArea checks the relative positions and copies in the
appropriate order to make copying work.

If your virtual object is smaller than (Dimension) x (Dimension), you
could consider using an Xt widget, and then "scrolling" it by using XtMoveWidget (which conveniently also moves any subwidgets), and by
processing Expose and GraphicsExpose events (which you probably have to
handle anyway).

If your virtual object is larger, especially if there are any windows or widgets covering the region to be scrolled, then scrolling pixels in a
way that looks nice is harder. You may discover
XSetSubwindowMode (IncludeInferiors), and then discover it doesn't
really help. :)
-WBE

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

This is a MIME GnuPG-signed message. If you see this text, it means that
your E-mail or Usenet software does not support MIME signed messages.
The Internet standard for MIME PGP messages, RFC 2015, was published in 1996. To open this message correctly you will need to install E-mail or Usenet software that supports modern Internet standards.

Winston writes:

Sam <sam@email-scan.com> writes:

I would like to efficiently scroll a rectangle within my drawable by a specified amount. That is: shift all the pixels in the rectangle in
the horizontal and/or vertical direction by some specified
amount. Afterwards there will be some exposed part of the rectangle
that I'll proceed and render appropriately, but for now I'm trying to determine what is the most efficient way to scroll the rectangle.

In any of X11R{5,6,7}, I've been able to use XCopyArea to scroll
overlapping areas up, down, right, left, or obliquely just fine. I
suspect XCopyArea checks the relative positions and copies in the
appropriate order to make copying work.

I suppose that this ambiguity cuts both ways: if one was looking to
implement the server-side of X11Rn, then it would be better to assume this
to be the case, since it doesn't explicitly state that the effect of an overlapping CopyArea is unspecified.

If your virtual object is smaller than (Dimension) x (Dimension), you
could consider using an Xt widget, and then "scrolling" it by using XtMoveWidget (which conveniently also moves any subwidgets), and by processing Expose and GraphicsExpose events (which you probably have to handle anyway).

I am not using Xt; rather I'm working on my own widget set: https://www.libcxx.org/w/ that's implemented on top of libxcb, which offers nothing more, or less, than a basic C wrapper for the wire protocol.

If your virtual object is larger, especially if there are any windows or widgets covering the region to be scrolled, then scrolling pixels in a
way that looks nice is harder.

I figure that the server can shove the pixels much faster than me, manually; and let me know what, if anything, got exposed. Exposure handling may
generate some additional noise, but I think the end result will still be
faster than by manually rerendering everything. My observation is that on modern hardware even if I don't change the backing-store from its default NotUseful, after mapping I do not get any further exposure events if another window overlaps mine's, and it goes away and reveals some bits. And in my
use cases I don't expect to have my own inferior children obscuring my
scroll area.


-----BEGIN PGP SIGNATURE-----

iQIcBAABAgAGBQJagRgsAAoJEGs6Yr4nnb8lv6gQAKKvB4h6DOJPLluPqNghXDkJ cRPftPgoCx9FQvbB7txQ/w1x3ITCzv5hMC+lFPGW3Vr6hWuZgSUdfSSzpH82Pc3E 1iHa1uLepMW93gzCIBCxc5b5cJJMin6GXP9L9He2Ow97YaJy51Qk4UoWfCpj8ggB j0zG9lnUDSOxFKpRlIaSz2EcpoJYAr+eMCXPMWy2nKXGHB3pfJGDtMnD3/VfA7Gp +sxADxeTkzQgNQi76VeH5sutpwHRQW1zKFeOerZRfx8BZdu/FNqA57WQx80WTFoZ 9nZF+zcav4FLBZ0vak/MEh70erRDkLDxEAPRX86wjcjsFRj9FesYnaIPAHRfMVhS iRD9maC5ubEgSkC8iWeuxiTH8+PlGipQuPs059A+npWQEd5251DXlzfts+oHumTH TUaf1l9j7k6PG/Q+IItP3G7DBujP7Q/FQIPTICKgUdrOzsNYSrv7GR1p7ZI5xhIK PsypsfxIi5mQ4kjQQTshhNGnlkeN90Ldq7c8ooKMyfP30jT17K743xpqyIFlxpCY rD9ash/ziaYOnlWuCccMDgHb/Ls39NDOTP2RbpZqdNY5tlIuZGRvvyXuM9SEfjpk T5+RGuVhgUVDPs/AWeR/gz+HlZbvxtu1paLs9Jmch08wK8Jl+oF3xGhNvFDcmyWG Vo4DD/L1ckyMeuLHhZe4
=gfao
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)