Quote Originally Posted by bridgman View Post
I think we'll end up having to do that when the offset between src and dest is very small (eg a few lines). For larger offsets, I *think* it would be faster to copy N lines at a time.
May depend on the per operation overhead as well.


Yeah, I'm not sure we clearly understand where the bottleneck is on resize. I'm starting to think that it might be the compositing loop redrawing the new window to the front buffer, not the driver actually resizing the window. I find resizing to be un-noticeably fast on my system but I'm running an RV570 and a quad-core CPU; need to re-test on some slower hardware.
IME it also depends a lot on the client; with some clients resizing is super-snappy for me with compiz, with others it's sluggish. I suspect some clients do a lot of unnecessary redraws on resizing.


I need to learn more about gradients; right now I don't understand why we even need shaders. It seems like we should be able to draw triangles and let the interpolators do all the work; maybe there's an edge matching problem or something. All I can say right now is that it seems like we should be able to do something, but I haven't talked to the devs about the problems yet.
Another problem right now is that the EXA core never even calls the driver Composite hooks for gradients (or solid pictures), because so far no driver could handle them.


Trapezoids seem like they should be easy to break down to triangles as well and I know both hardware and software folks have worked very hard to make all the edges match in OpenGL; again, this is spoken with the clarity of ignorance
Yeah, it could be that easy if the RENDER rasterization rules matched those of hardware / 3D APIs... alas, unfortunately they don't.

Also, again there are no EXA driver interfaces for trapezoids yet.