On Sat, 21 Sep 2019 13:47:40 +0800 (CST) Jing <chenjing...@126.com> said:
> I use efl-1.21.1(define the image/rect in edc file) to develop in linux > environment. Using X11 and framebuffer. Looking forward to your reply， > thanks. what framebuffer engine/rendering path? in x11 what rendering engine? what windowmanager/compositor? tl;dr; short version: this stuff is complicated and crosses lots of software boundaries (protocols, kernel vs xserver vs client vs multiple toolkits vs compositor etc.). i'll cover some of those details below s you didn't tell me everything above. if you are using the fb engine for framebuffer rendering, then it has no vsync or double buffering support. it's built on the old /dev/fb interface and mmaps the existing fb and renders to cpu local memory then copies stuff to the framebuffer. thus it will tear at times. that's life with fbcon as it doesn't have buffer swapping semantics (it could allocated double-height buffers and do panning... but it still has no ability to explicitly vsync this so will still lead to tearing). that's why there is a drm engine... thus sues drm/kms as the framebuffer interface which does have swapping/atomic/vsync semantics and will then not tear. this is the engine that e uses as a wayland compositor (well drm or gl_drm depending if you have gl accel on or not). with software rendering in x11, no mechanism exists to explicitly avoid tearing for clients (ignoring the double buffer extension in x which doesn't actually provide SWAPPING mechanics and leads to worse performance anyway. it at best does copies from the backbuffer to the window... - i can go into gory details if you want). if you have no compositor in x then rendering goes straight to the frontbuffer framebuffer. by that i mean the update regions once filled by the cpu in shared memory are COPIED over to the window which lives in the framebuffer. if it's composited then these regions are copied to the pixmap that represents the window and the compositor will, at some point after that render that pixmap to its own backbuffer and swap and the compositor itself may also tear in its presenting to the screen depending on the compositor you have. i have seen compiz (the compositor ubuntu has used for unity) EXPLICITLY do copies to the front buffer to try to do partial update rendering to reduce rendering amount BUT at the expense of always tearing. that's why i asked. efl/e only does this in the software path - with the gl path we always buffer swap and request vsynced swaps if asked (tear-free0 for the compositor. we can't do anything about the client rendering, but if clients use gl as well and do swaps then they have a chance of the x implementation doing proper buffer swaps (not copies) from the gl backbuffer to the composited target pixmap (exchange the buffers if sizes match). again - depends on your compositor/wm and how it may reparent windows and do frame draws. e doesn't draw frames via x when compositing but does it in-compositor making the client pixmap an exact 1:! of the client window with frame drawn around it only in the compositing step. other wm's compositors may reparent and raw frame inside the parent window, thus forcing x to copy to the composited pixmap, thus tearing... wayland avoids this by using CSD (client side decorations) and being an explicit buffer presentation protocol, thus being designed from the ground up to avoid tearing as long s e everyone does everything right. tearing in x is "part of life". if you have the right compositor you can reduce tearing but it will ever go away in x. in theory i could have designed a private x11 display protocol between efl and e and literally do what wayland does - present whole pixmaps with update/damage region metadata via x client messages and have the x compositor render them without tearing but it'd be then only for efl apps using software rendering in enlightenment and nowhere else. this would still result in extra copies if e is also software rendering as a compositor and i'd have to actually do a private shm buffer sharing scheme between efl clients and x... and even then the compositor itself will still tear as there is no way for a software rendering compositor to ensure it gets to atomically present an updated render buffer in x11 ... unless we move to gl. :) > At 2019-09-20 20:55:53, "Carsten Haitzler (The Rasterman)" > <ras...@rasterman.com> wrote: > >On Fri, 20 Sep 2019 18:48:14 +0800 (CST) Jing <chenjing...@126.com> said: > > > >> Hi all, > >> > >> > >> I met a problem that when i slide the screen(mouse move), the edge of the > >> image or rectangle object will tear( appear jagged, see my attached > >> snapshot). I have set various values with ecore_animator_frametime_set, but > >> there is no improvement. What can I do to fix this issue? Please help, > >> thanks a lot. > > > >what environment? x? wayland? what is rendering the object? what kind of > >environment? > > > >-- > >------------- Codito, ergo sum - "I code, therefore I am" -------------- > >Carsten Haitzler - ras...@rasterman.com > > _______________________________________________ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- Carsten Haitzler - ras...@rasterman.com _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
