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
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
config wasa being chosen as it was done by hand not accounting for
multisample buffers. now using glxchoosefbconfig instead and it works.
SVN revision: 79232
This pointer could be NULL if the window was hidden before calling
glMakeCurrent, which would make the program crash. In fact, at least
elm_win hides the window before actually deleting it (thus calling this
function).
SVN revision: 79017
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