Hi Carsten,
Thanks for your reply. You are saying "drm can be vsynced and tear-free even if
it is configured without gl-drm", right?
But from source code in src/modules/ecore_evas/engines/drm/ecore_evas_drm.c, it
seems only enabling vsync with option BUILD_ECORE_EVAS_GL_DRM, how can we
build efl to enable vsync without gl-drm package:
#ifdef BUILD_ECORE_EVAS_GL_DRM
if (tinfo && gl)
{
char *num;
Evas_Engine_Info_GL_Drm *einfo = tinfo;
einfo->info.vsync = EINA_TRUE;
num = getenv("EVAS_DRM_VSYNC");
if ((num) && (!atoi(num)))
einfo->info.vsync = EINA_FALSE;
einfo->info.dev = edata->dev;
einfo->info.bpp = edata->bpp;
einfo->info.depth = edata->depth;
einfo->info.format = edata->format;
einfo->info.rotation = ee->rotation;
einfo->info.output = edata->output;
if (!evas_engine_info_set(ee->evas, (Evas_Engine_Info *)einfo))
{
ERR("evas_engine_info_set() for engine '%s' failed", ee->driver);
goto eng_err;
}
}
else
#endif
Looking forward to your reply, thanks.
At 2019-09-23 22:13:11, "Carsten Haitzler" <ras...@rasterman.com> wrote:
>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
