We must check whether source image has been loaded or not before
enqueueing draw commands. Otherwise, cserve2 may not have a specific
loader and then it does not load the source image and the enqueued draw
commands dereference the NULL pointer "data" from source image.
Patch by: Paulo Alcantara <pcacjr@profusion.mobi>
SVN revision: 82483
evas_gl_shader.c file and made an internal generic caching api in
evas_gl_common.h for use in other places ie. evas_gl.
Then implemented evas_gl surface cap. caching code in gl backend to
accelerate the engine creation.
SVN revision: 82321
it is "const char * const *", not "const char **", and it was triggering a warning in our code.
it's just constness and will not trigger an error in our user's code, just an warning that he should fix.
SVN revision: 82278
evas_common_font_draw() should be called with glyphs array for now,
instead of intl_props.
This patch should fix ticket #2149.
Signed-off-by: Paulo Alcantara <pcacjr@profusion.mobi>
Patch by: Paulo Alcantara <pcacjr@profusion.mobi>
SVN revision: 82229
Since we are already inside wayland_egl code, force this env var to
avoid the EGLNativeDisplayType autodetection (done by EGL code), which
seems to be incorrect.
This commit should fix ticket #1972.
Note: revert this as soon as EGL autodetection gets fixed.
SVN revision: 82183
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
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