It is not necessary to dynamically link to glReadPixels since
this is not an extension. This code wouldn't even work on some
devices.
Also, the pixels returned are not premultiplied (yeah >_<)
And some devices (EGL) don't support GL_BGRA... so glReadPixels
would just fail and not fill in the pixels. Conversion is required.
@bugfix: structure fb_var_screeninfo does not have a colorspace field
defined in linux/fb.h, so (for now) comment out code which was
referencing that field. Not sure what the intent was here, but build
was broken because of this.
Signed-off-by: Chris Michael <cp.michael@samsung.com>
GL_READ_FRAMEBUFFER isn't defined when compiling for Wayland
Thanks Stefan for the report.
Also, import GL_FRAMEBUFFER overrides from other GL files, so
that it points to the proper extension (_OES or _EXT if applicable).
While most framebuffes use stride = width, some may have stride bigger
than width to provide better alignment. Then we must always use stride.
Thanks to Arjan van de Ven, the one that spotted the issue.
@fix
This will be needed by the filters for proxy rendering,
for textures and maps (displacement).
Add new engine functions to unleash the (sluggish) power of glReadPixels.
The idea is to be able to bypass glReadPixels later, so 3 new APIs are
added:
- surface_lock
- surface_read_pixels
- surface_unlock
They must be called in that order.
Note (for history):
glReadPixels was always getting the wrong data during first draw,
but the right data during a redraw...
Why? Well simply because for OpenGL itself, the image had never
been drawn in teh first place! Only the Evas GL context knew
about the image drawing, as it was queued somewhere in the pipe.
One line solution: Call evas_gl_common_context_flush before
doing anything else.
FrameBuffer can be tricky with all combinations and it's hard to tell
users to send useful information, then print the information we use so
we can get useful bug reports.
clean evas_fb_main.c so it returns -1 to indicate invalid fds, same as
open() and what is written in evas_fb.h example.
call fb_cleanup() in all error conditions and always return -1 in
fb_postinit() if we did call fb_cleanup().
@bugfix: Removed hardware acceleration fields from engine structure.
These are now located inside the buffer management code itself, so no
need for them here.
Signed-off-by: Chris Michael <cp.michael@samsung.com>
@bugfix: Set cached image alpha flag properly
This fixes issue where cached image alpha flag was not set properly.
Set it according to the outbuf's destination alpha flag.
Signed-off-by: Chris Michael <cp.michael@samsung.com>
@bugfix: Check (and set) buffer validity before calling
framebuffer_send. This fixes an issue where buffer was not valid,
causing next_update_get to do full Copies.
Signed-off-by: Chris Michael <cp.michael@samsung.com>
@bugfix: We cannot call framebuffer_set from within the send function
because if we are not vsync'd then framebuffer_set would never be
called and thus the buffer would not be marked as valid, causing full
Copies to happen.
Signed-off-by: Chris Michael <cp.michael@samsung.com>
@bugfix: Draw to the front buffer first, instead of the back buffer.
Frenchie says this improves the "initial rendering delay" of expedite
tests. Originally, we were drawing to the back buffer first, then
flipping it onto the crtc when drawing was done. This presented a
"perceived" rendering delay when running expedite tests as it would
wait for the back buffer to be drawn before presenting it. Personally,
I think it is not good to draw directly to the front buffer first as
it may get presented "incomplete" ... but cedric says it draws fine so
we'll leave it starting on the front buffer (for now).
Signed-off-by: Chris Michael <devilhorns@comcast.net>
@feature: Add support for EVAS_DRM_VSYNC environment variable to
@feature: Add support for marking a Framebuffer as dirty.
@bugfix: Fix color mask values for evas conversion functions.
@bugfix: Start with using the Backbuffer for drawing.
@bugfix: Fix previous Slowness with evas_cache image data.
Signed-off-by: Chris Michael <cp.michael@samsung.com>
@feature: Add ability to render software buffers using vsync or not
@bugfix: Fix drmModeAddFB to use proper depth & bpp when adding FB
@bugfix: Fix mmap to use NULL (not 0) so that kernel assigns memory
address.
Signed-off-by: Chris Michael <cp.michael@samsung.com>
@bugfix: this cleans up the Outbuf structure by removing unused
fields, Fixing some function declarations, and defaulting the number
of buffers to 2 (double-buffering)
Signed-off-by: Chris Michael <cp.michael@samsung.com>
@feature: Start on hardware Plane support
- Add Plane structure
- Store list of Planes in the Output buffer
Signed-off-by: Chris Michael <cp.michael@samsung.com>
- Typically this will come from ecore_evas and be used by evas to
allocate hardware accelerated buffers (gbm, tbm, etc)
Signed-off-by: Chris Michael <cp.michael@samsung.com>
@feature: Add code to check if async page flipping is supported by the driver.
@bugfix: Add code to get the proper drm driver name when we init the card.
@bugfix: Use drmOpen when opening the card so that any sub-driver gets initialized.
@bugfix: Add some debug/testing code to enumerate planes.
Signed-off-by: Chris Michael <cp.michael@samsung.com>
updated sooner.
@bugfix: set framebuffer on crtc earlier in process
@bugfix: Set the rendered image's alpha flag to be equal to the output buffer's
Signed-off-by: Chris Michael <cp.michael@samsung.com>
When rotation is 0, we need to advance the destination pointer in the
X direction by a Multiple of Bits-Per-Pixel...not an addition.
Signed-off-by: Chris Michael <cp.michael@samsung.com>
This looks like a typo: if (animated > 1) when animated is a... Bool!
So, I am not entirely sure why this bug is visible in case of gif
proxies, all it seems that the load_data function may be called
multiple times when the object is visible. So gif close and reopen
happen properly, and the first frame can be decoded.
When running in direct rendering mode, properly support partial
rendering if the extension is properly supported.
Also, fixed the SwapBufferwWithDamage rectangle coordinate bug.
It wasn't properly y-inverted before.
even though we don't support rectangle bits in texture targets for
texture-from-pixmap the code checked and complained - problem is it
checked the wrong thing. fixes CID 1135267
Summary: Ensure Evas's eglContext when several eglContexts are used.
Test Plan:
1. Native GLES application works with evas_object_image_native_surface_set
2. One Evas object works with evas map.
Reviewers: seoz, tasn, cedric
Reviewed By: cedric
CC: cedric, raster
Differential Revision: https://phab.enlightenment.org/D534
Signed-off-by: Cedric BAIL <cedric.bail@samsung.com>
Summary: This patch is for QUADRUPLE window buffers.
Test Plan:
When enlightenment uses quadruple buffers or window system can support quadruple buffers,
application can use quadruple buffers with partial rendering
Reviewers: tasn, seoz, raster
Reviewed By: raster
CC: cedric
Differential Revision: https://phab.enlightenment.org/D527
Quick and dirty solution to support the OpenGL engine:
[1] Allocate CPU buffers
[2] Render text and process all effects to these buffers
[3] Push final image as an OpenGL texture.
This patch implements [1].
Summary: Ensure eng_window_use in image_content_hint_set
Test Plan:
1. make native OpenGLES application.
2. set evas object image with evas_object_image_native_surface_set.
3. GLES Application try to call eglMakeCurrent with own eglContext, then resize evas object resize
Reviewers: Hermet, raster, cedric
Reviewed By: cedric
CC: cedric, seoz
Differential Revision: https://phab.enlightenment.org/D523
Signed-off-by: Cedric BAIL <cedric.bail@samsung.com>
this changes the internal encoding of font glyphs in evas to use 4bit
uncompressed if small, or 4bit rle (run length encoded) if larger.
this caves at least 50% of memory on fonts - and more if bigger. with
large fonts (40-80pixel size) we can save in the region of 80% of
memory used for glyphs. this also happesn to allow speedups in
rendering too.
if alpha4 is possible (desktopgl) then use it for fonts as this should
cut memory in half for them and possibly speed things up due to less
memory bandwidth needed