On Mon, 23 Sep 2019 14:02:09 +0800 (CST) Jing <chenjing...@126.com> said:
> 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. there's gl_drm that needs gl accel an also just drm which is software rendered, but uses kms/drm to display buffers. this will be vsynced and tear-free. the fb backend will tear because of the reasons i already gave in the previous mail. :) > --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 -- ------------- 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
