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
This works in linux and windows, and should fix shm_detection on BSD (including Mac)
BSD, Mac and solaris users : please check that it compiles and shm_open is detected
SVN revision: 69612
Subject: image data get/set pairing issue
I found a bug about pairing
evas_object_image_data_get/set(eng_image_data_get/put).
It was added to count checked_out for paring
eglMapImageSEC/eglUnmapImageSEC.
In case of calling evas_object_image_data_set() twice after calling
evas_object_image_data_get(), dyn.checked_out has -1.
Then, if evas_object_image_data_get() and evas_object_image_data_set()
is call, it can't call eglUnmapImageSEC().
If dyn.checked_out has minus, it can make some problem.
So, I fixed this problem.
Please find enclosed patch file and let me know if I misunderstood.
SVN revision: 68504
From: Thanatermesis <thanatermesis.ecvs@gmail.com>
Subject: [E-devel] LDFLAGS with -Wl,-z,defs
Aparently if you add the option "-Wl,-z,defs" to your LDFLAGS, there's some
libs that doesn't compile, like evas and e_dbus, there's some logs:
SVN revision: 68464
subject: [E-devel] [Patch] Add override gl apis for osmesa
When an application use glBindFramebuffer or glBindRenderbuffer via
evas_gl after loding libosmesa.so,it shows segment fault.
Because glBindFramebuffer and glBindRenderbuffer are not overrided.
So, I fixed it.
SVN revision: 68391
NOTE: I would like to do the same with software SDL 16bits engine.
But as we don't have a buffer_16 backend, I am likely to just remove
it and use buffer conversion code to match a 16bits target. This
will come with a performance impact, that will make it useless. So
I am just tempted to completly remove it.
SVN revision: 68352
void pointer causing a segfault. The attached patch fixes the issue
and allows an expedite run to complete.
By: Will Newton <will.newton@gmail.com>
SVN revision: 67543
option.
It should have been OR instead of AND operator.
When the image object alpha is on "OR" the rotation angle
is not "0", direct rendering isn't allowed. However,
allow direct rendering if EVAS_GL_DIRECT_OVERRIDE=1 is set.
SVN revision: 67521
This optimization is significant for rendering to a large surface
because it'l save an extra copy overhead as well as an extra rendering pass.
To enable it, you can give EVAS_GL_OPTIONS_DIRECT hint in the surface
config options_bits. The following conditions have to be met in order
for evas to render directly into the Evas' window. If they are not met, the
engine will fallback to rendering to an FBO as it normally does.
conditions:
1.) All the GL calls have to be called using the pixel_get_callback function.
This is necessary for the evas object order to be maintained.
2.) Alpha must be disabled on the image ojbect that renders evas_gl.
3.) No rotation allowed.
One way to override above condition is to set EVAS_GL_DIRECT_OVERRIDE=1 but
there is no guarantee in its behavior.
Currently, this optimization is added for gl_x11 engine only.
SVN revision: 67388