- Added (w,h) <=0 dimension check for evas_gl_surface_create()
- Changed evas_gl_make_current to return error when either
surface or context is NULL. Semantically, this was allowed
before but it was changed to reflect eglMakeCurrent behavior.
- evas_gl_make_current - detached any previously attached
buffers before attaching new ones to an FBO during a make_current.
- Used dynamic memory for extension string allocation for safety.
SVN revision: 72926
Nowadays, this engine is completely useless. Windows users (>= XP) use
only 32 bits depth color, so let's kill that engine. Less code to
maintain for me.
SVN revision: 72494
handling in EGL environment. Also fixed some minor issues
regarding checking surface capabilities. Apparently, some
GL drivers do not allow FBO to only have depth or stencil
buffers attached to the FBO without the color buffer attached
to them.
SVN revision: 72108
For no bidi: just don't set the bidi stuff. I.e paragraph props and the
other stuff (including text_props_direction_set). If you disable BiDi you most
likely want to disable shaping as well.
For no shaping: Disable bidi (i.e don't set direction) and pass
EVAS_TEXT_PROPS_MODE_NONE to info create.
This will prove especially useful for textgrid, but not only.
SVN revision: 72032
NOTE: as librsvg is a massive source of bugs in e17, it is now
removed from evas. You can still use librsvg by using the
evas_generic_loader. Please not that you need to properly delete
it from your disk if you don't use a package manager. The file to
remove :
/*/lib/evas/modules/loaders/svg/linux-gnu-i686-1.2.*/module.so
SVN revision: 71223
Now evas will in all case do the layout during the prepare stage. It will do that
once and as long as the text didn't change. This does improve by a factor of at
least 2.3 in all expedite test case except the text change that only get a 30%
increase (I expect a drop in performance on non pipe rendering for text change
expedite test only, but this case is not common in real life).
This also fix the issue that show random size glyph when using pipe rendering.
SVN revision: 71220
Currently, this feature is only supported in EGL/GLESv2 environment
with GL_IMG_multisampled_render_to_texture extension supported.
_____________________
from: (sanghee park) sh15.park@samsung.com
Dear all,
I compose this mail to ask reviewal this patch about multisampling on the evasgl.
I want to make multisampling capacity to enhance rendering quality of the evasgl.
But if MSAA is applied always, this have possibility lowering rendering performance,
I separated user's input level to high, mid, low, none.
If you want to test this patch, try to examine rendering qulity on EGL circumstance with multisampling level.
Plaese review it, and any suggestion will be appreciated.
Best Regards,
SangHee
SVN revision: 70992
Mainly, glDeleteBuffers was being called instead of glDeleteRenderbuffers.
Also, there was an error when checking if surface is valid.
SVN revision: 70870
now seriously...
Introducing Cache Serve 2.
This cache server will initially load images for clients connected to
it. It starts slave processes to load these images, and share the loaded
images through shm with the clients. All the connection done between
clients and the server goes through sockets.
The cserve2 build option is turned on by default, while the old cserve
was disabled, but in order to make clients use it, the environment
variable EVAS_CSERVE2 must be set, and a server must be running.
Clients will try to find the socket on a specified location using the
environment variable EVAS_CSERVE2_SOCKET. If it's not defined, then the
XDG_RUNTIME_DIR path should be used, and finally HOME, TMPDIR and /tmp.
SVN revision: 70699
(Trying it again since this commit broke evas build yesterday.)
Previously, evas_gl_surface_create() didn't actually do
the render buffer attach to the the FBO. It was performed when
the make_current was called for the first time. The issue
was that even though the surface was successfully created with
the given configuration, there was a possibility of make_current
failing with the error message "FBO not complete" because of
the surface configuration.
So, I've added a piece of code that checks the FBO
capabilities beforehand to set up a available surface configurations
so that it doesn't have to fail during make_current for unsupported
surface format.
Also, I've changed the surface config in a way that once the
user calls evas_gl_surface_create(), evas gl sets the config
parameter with configuration that evas_gl is actually using.
SVN revision: 70680
Previously, evas_gl_surface_create() didn't actually do
the render buffer attach to the the FBO. It was performed when
the make_current was called for the first time. The issue
was that even though the surface was successfully created with
the given configuration, there was a possibility of make_current
failing with the error message "FBO not complete" because of
the surface configuration.
So, I've added a piece of code that checks the FBO
capabilities beforehand to set up a available surface configurations
so that it doesn't have to fail during make_current for unsupported
surface format.
Also, I've changed the surface config in a way that once the
user calls evas_gl_surface_create(), evas gl sets the config
parameter with configuration that evas_gl is actually using.
SVN revision: 70617
NOTE: This should be part of evas_render itself and not
delegated to the engine. So cleaning things to make it easier
during evas_render rewrite.
SVN revision: 70503
NOTE: some of this function should be moved as inline, but that's to late for a change
I think. So we will fix that if needed.
Second point, I am not happy with is eina_inarray_insert and eina_inarray_insert_at. The
naming is really poor.
SVN revision: 70352
Christopher Michael
Sung Park
Carsten Haitzler
Rafael Antognolli
Vincent Torri
Jiyoun Park
Tom Hacohen
ChunEon Park
Cedric BAIL
Jihoon Kim
Iván Briano