Evas GL direct rendering mode didn't properly take into account
the image object's clipping information and clip the region that
it was directly rendering to. Hence there were issues with the
direct rendering region drawing over the objects that are sitting
on top of it.
Also, cleaned up the direct rendering coordinate computation code
and a nasty dependency with image object that should have been
removed a long time ago. Basically the evas-gl engine was directly
accessing the image object data structure for its data when it
really should have just passed along necessary information.
Evas_GL Direct rendering is an optimization path that renders
directly to the window if conditions are met. Because evas gl
backend used to re-render the entire screen, evas_gl direct
rendering didin't have to concern with partial region rendering.
Now that partial rendering/swapping has been applied to evas gl-
backend, evas_gl direct rendering also had to take into account
clip regions. in order to properly apply it, some adjustments
were made to the engine functions and etc.
Evas engine is created per window but evas_gl engine was not properly
updating the engine info for new windows that are created. So, addressed
the design issue by passing engine_data to evas_gl engine apis..
Resource contexts/surfaces are used for creating resources within Evas_GL.
In oder to handle Evas_GL runnig from different thread than the main one,
a resource context/surface pool was used. This turned out to be unnecssary
as they are not used very frequently. So, I got rid of the pool and
made the resources create as needed.
downscaling. This makes quality much better and "at best"
equates to a 16 point sample (2x2 linear interpolation samples,
where a linear interpolation sample equates to a 2x2 sample).
This will have perfomance impact, but the quality is worth it and
makes it closer to software downscaling in quality. It supports
2x2, 2x1 and 1x2 oversampling. YUV not done, nor image mask
(font shaders not needed).
weren't set properly where if a program uses evas_gl to do GL rendering
in direct rendering mode and then use a pixmap to do native
GL rendering in the same program, native pixmap rendering would
also fall into the direct rendering path and not render anything for
image object. It's been fixed.
SVN revision: 79493
I've tested make -j 3 install and it works nicely
I've tested expedite with software and opengl xlib,
and it works. Not tested other engines, so please
report any problems (engines or other) on the ML.
TODO: examples and tests, I'll add them later
ISSUE: Eina_Unicode size check. It indirectly depends on
eina_config.h, which is created at the end of the
configure script. So its size is always 0. I don't
know how that size is used, so I can't do a lot,
for now.
SVN revision: 78895
Sung W. Park
Carsten Haitzler
Sung Park
Vincent Torri