Hi Carsten, Thanks for your reply. Correction: Actually, we didn't use X11 and only use frame buffer, based on our flash and memory performance considering, we are using a light configuration, here is our configuration for your reference. Our system do support basic drm, but vsync needs gl_drm(we didn't have gl accelerate), do you have any simple option to avoid tear issue or implemented a simple ping pong buffer mechanism.
--with-tests=none --disable-systemd --disable-doc --disable-cxx-bindings --enable-fb --disable-cocoa --disable-poppler --disable-spectre --disable-libraw --disable-xcf --disable-libmount --disable-audio --disable-avahi --disable-pulseaudio --disable-xinput2 --disable-xim --disable-scim --disable-ibus --disable-elua --without-glib --with-x11=none --with-opengl=none --without-x --without-mount --without-umount --without-eject --disable-image-loader-bmp --disable-image-loader-dds --disable-image-loader-tgv --disable-image-loader-xpm --disable-image-loader-webp --disable-image-loader-wbmp --disable-image-loader-tiff --disable-image-loader-tga --disable-image-loader-psd --disable-image-loader-pmaps --disable-image-loader-jp2k --disable-image-loader-ico --disable-image-loader-gif --disable-gstreamer1 --disable-xinput22 --disable-librsvg --disable-vg-loader-svg --disable-vg-loader-eet --with-crypto=none --disable-doc --disable-v4l2 --disable-libvlc --with-net-control=none --disable-libeeze --disable-gesture --disable-xpresent --disable-cserve --disable-always-build-examples --with-profile=dev --disable-physics --disable-valgrind --disable-quick-launch Looking forward to your reply, thanks. At 2019-09-21 15:53:12, "Carsten Haitzler" <ras...@rasterman.com> wrote: >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
