Hi Everybody Jeremy, thanks for answer I will profile the hack on Leopard with latest X11 to see the bottleneck. Meanwhile I can right away name the main X11 API that's drives this hack - it's XCopyArea - previously it was specifically accelerated. The source and destination are the same window, that's why theoretically this hack should be very fast - we take pixels from window and copy them in the same window. P.S. XCopyArea emulation (window->window) is the major bottleneck for pure OS X port as well btw because there is no low level API in OS X that can do such blits. Best regards, Platon
On Jul 26, 2009, at 12:26, Platon Fomichev wrote:
Hi Everybody
Jeremy, thanks for answer I will profile the hack on Leopard with latest X11 to see the bottleneck. Meanwhile I can right away name the main X11 API that's drives this hack - it's XCopyArea - previously it was specifically accelerated. The source and destination are the same window, that's why theoretically this hack should be very fast - we take pixels from window and copy them in the same window.
P.S.
XCopyArea emulation (window->window) is the major bottleneck for pure OS X port as well btw because there is no low level API in OS X that can do such blits.
Those blits are exposed via libXplugin and are used in rlAccel. This XCopyArea issue was the main reason I suspected that rlAccel being removed was the primary culprit. But when I re-enabled rlAccel, I only got a ~30% performance boost (from 7 to 9 fps). Granted 30% is a big gain, but seeing those numbers so low makes me think there is a bigger bottleneck somewhere else.
participants (2)
-
Jeremy Huddleston
-
Platon Fomichev