- EVAS_CALLBACK_FREE and EVAS_CALLBACK_DEL were doing the same thing
at different stages, causing a segv due double free.
- extn->file.updates and its Ipc_Data_Update were leaking.
PS: I can't backport this to 1.7, but the problem is still
there. Could someone look into those?
SVN revision: 81304
This is in preparation for threaded render landing: the render thread will
hold a reference to a text object's glyphs while it hasn't been rendered
yet (and will drop that reference after drawing). This changes the internal
API a little bit (evas_common_font_rgba_draw() now takes an Evas_Glyph_Array
instead of an Evas_Text_Props).
SVN revision: 81183
line position is slightly different between gl drivers.
I have no idea why it is. So added to work differently based on the manufacturers.
This work may be based on the renderer. If you can test it with much drivers then please test and fix.
Also changed the ENV name from EVAS_GL_LINE_NO_OFFSET_HACK to EVAS_GL_LINE_OFFSET_HACK_DISABLE.
SVN revision: 81016
I tested gl line drawing on a few devices and found the x line start position was 1.
On the other hand, our evas draws the line on start position 0.
So it needs to shift by 1 pixel if evas is working on gl backcned.
SVN revision: 80734
Implementing support for loadables modules. It makes the engines been
loaded when they are needed. It not breakes the api, so each engine
still has its own api.
The implementation basically is:
* Functions that creates Ecore_Evas, for example
ecore_evas_software_x11_new, request to load its module and then get
the module's function to create the Ecore_Evas.
* The other functions such as \(.*\)_window_get from the Ecore_Evas
its interface and then call the appropriate method.
* As there is no unified interface to communicate with the engines
(not break api problem), all interfaces were declared in
ecore_evas_private.h
* Now the data necessary for each module is not declared in the
Ecore_Evas_Engine structure, instead of this, the struct has a void
pointer that is used by the modules.
* In this first moment engines as software_x11 and gl_x11 were put
together in the same module, but obviously exporting all the things
necessary.
SVN revision: 80280
After agreement in the mail list, core developers agree to remove this
engine that was not being supported for a long time.
Given that most operations Evas uses are not accelerated in DirectFB,
or at least hardware that exclusively supports DirectFB, it's better
for those people to just use Evas/Ecore software (buffer) rendering
and expose DirectFB's framebuffer as destination surface.
SVN revision: 80232
direct rendering and then another image object using Native
Surface rendering, there was a potential for it to fall into
the same direct rendering path.
Also, fixed some minor Evas GL extension bugs that came from refactoring.
SVN revision: 79532
EGL 1.4 spec Section 3.5.1: If there is already an
EGLSurface associated with win (as a result of a previous
eglCreateWindowSurface call), then an EGL_BAD_ALLOC error is
generated.
So that this eglCreateWindowSurface() will fail if the egl driver is
a strict conformance to the spec.
SVN revision: 79505
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
x1, x2 shadow something in the math library.
Would probably be better to turn off -Wshadow, but for some
reason people think this there's some value in it...
Signed-off-by: Mike McCormack <mikem@atratus.org>
SVN revision: 79446
Unfortunately setting unused variable to zero still produces
a warning about variables being set but not used (on gcc 4.6.3).
Signed-off-by: Mike McCormack <mikem@atratus.org>
SVN revision: 79445
This was removed on latest mesa, and seems to don't belong to GLES. See
the specification at http://www.khronos.org/registry/gles/.
Additionally, it wasn't being used anywhere.
SVN revision: 79400