On Sun, 4 Apr 2021 17:40:21 +0900 Florian Schaefer <list...@netego.de> said:
So ... I think there is some lack of information here and thus people come to the wrong conclusions. Let me expand. when you alt+tab this bring up "winlist". this is the name of the module and in e's code. under settings -> windows -> window switcher you'll find the config options for this. the below is long, but please read so you can learn and make it easier to talk about things. it'll help you identify things that are probably costly much more correctly etc. 1. the old winlist will have faded in and zoomed in just as before. the time this transition takes in the animation has gone down vs the old theme. i cut down transition times. 2. i added an ability for a background object to be behind the winlist covering the screen - this now exists and happens to just fade in a big dark rectangle on top of everything below. everything below keeps updating/rendering as it used to, so if you are playing a video or whatever is going on down there - it continues to do so under this darkened rect. rendering a solid rect is the cheapest thing that can be rendered. a semi-transparent rect is not as cheap but is probably the next cheapest thing to render (well maybe rendering an unscaled image with no alpha channels might be a bit cheaper - depends on memory bus speed vs. cpu core speed or likewise gpu...). so this is not expensive. 3. i added a new large mode to winlist that has an "exposé" like "grid" of windows with large previews of all windows. i just switched on large mode by default too, so i don't know what mode you may have enabled there. 4. i added miniature preview support to the list mode code a while back but only if theme has the swallow regions to place the preview - the flat theme does, so a switch to flat will have instantly added those. 5. efl git has had a dithered shader for gl since last november. this applies to ALL rendering of EVERYTHING. every single thing goes through the dither logic in the shader. it used a 4x4 ordered dither matrix so there was a lookup in this small array and comparing the rounding delta to this matrix for every single pixel rendered .. every time it's rendered. a pixel may be rendered multiple times to produce a frame. i never noticed a hit - even on the slowest systems i had, but this is because even the slowest "didn't care" ... unless i looked at the gpu clock speed. then i noticed. also it only affected the slowest of my intel gpu's (on a i5-4200u). on my faster gpu's they didn't even clock up to handle it in my tests. yesterday i did some profiling and tuning and made the dither shader cheaper. it dropped to about 1/2 the cost with a 2x2 dither matrix. this is is still maybe about 15-20% more costly than no dithering. 6. i added a checkbox in the compositor render settings to now turn dithering on and off (on by default). you can toggle and see. 7. btw guys - i don't need the glxinfo - if e's compositor is set to opengl and it doesn't give you errors, it's using your gpu. 8. there are good reasons for dithering. when a gpu codes math to calculate pixels, it does it in quite high precision internally in floating point. that means a r, g, b or a value that is normally from 0 to 255 becomes a floating point value -o then has some math done for scaling, alpha blending and multiplying by other colors (fading in and out for example) and so on - so you end up with intermediate results that are higher precision than the 0->255 we read or write (can have 127.324). the problem is this cannot be represented. you either use 127 or 128... 127 is closer. this results sometimes in banding effects - they may be subtle but they do exist and i see them. dithering will take this limitation of 127 or 128 and spread the error across multiple pixels by having some be 127 and some 128 if they all must write the same color. it does this in a pattern that unless you zoom in pixel by pixel, approximates the 127.324 that was intended. yes - there is the possibility of a 30bit visual (10 bits per rgb) these days and i could look into enabling that if it exists and no alpha channel is needed, but the dither solution is universal and works everywhere - even on old gpu's. the cost is an extra bit of math every time we write out a pixel to take our higher precision internal gpu value and write out a lower precision 0->255 pixel value to a buffer. 9. software rendering CAN dither but only in the case of rendering to screens that are 16bpp, 15bpp, 8bpp or even 1bpp for example. internally evas will render in 32bit (8 bits per rgba so 0->255) and pretend this is what the screen really does and then in an extra pass at the end this is copied AND possibly rotated AND dithered AND converted to a lower screen depth in one go. this is an extra pass/cost but it massively improves quality on low depth screens. i doubt anyone hits this case anymore these days as compositing in x11 doesn't work on screen depths < 24/32bpp... well not that i've seen. 10. software rendering for evas is a special case implementation that is massively faster than using a software opengl implementation. it's totally usable, unlike software opengl for "real workloads" but it's usefulness will vary on the speed of your cpu and how many pixels need rendering and how complex the rendering is. evas's software renderer is threaded (it does the rendering work in a slave thread separate from the main loop thread) so an extra cpu core or 3 will help, but it won't use every core you have. i've experimented with this before and found that it ended up going nowhere. in some complex rendering where you are cpu core bound, it was much faster to use many cores, but when it was simple (rectangles, unscaled images) it was SLOWER than a single core (when the cpu was memory bound and we were really just thrashing the caches making them less effective). the issue probably could be fixed by using smaller tiles instead of strips, but that is a whole topic on it's own. 11. in compositing - if you sue software rendering, turn off the "smooth scaling of windows" as this is extra expensive for software to do. if using gl, it doesn't matter as much. 12. since both large mode and the list mode in winlist now support window miniatures, how a miniature is rendered matters. keep in mind miniatures are LIVE. if you are playing a video in your browser or in a video player or a cursor is blinking, the miniature will keep updating ... this makes them really nice and amazingly useful but also costly when being updated all the time 13. the way these miniatures are rendered -> e makes a mirror of the original window content (this is cheap - it just points to the original), and then places this in a duplicate of the window frame then causes this combined object to be rendered into a buffer. that means basically a full windows + border and shadow sized copy of the window is rendered at least once and on any update. this large image (so if window is fullscreen sized, this buffer will be a bit bigger than the full screen in size) is then rendered to the destination - when winlist appears this means rendering this to the winlist buffer as it is zooming in it will have a buffer of its own - in list mode this is the grey area you see, in large mode it's much buffer bug is "invisible" as it has an alpha channel - but it's still there as this buffer does zoom and fade in too. this winlist buffer is then also in turn rendered to the screen buffer. keep in mind that the window miniatures will render a bunch of frames when they start up as that's the show animation a window goes through - the normal cycle of its life, so all these miniatures will get re-rendered in full in their buffers for like 0.2 secs or so and then these buffers scaled down and rendered then these final buffer also scaled and rendered to the back buffer. if gl dithering is on, dithering affects every pixel in every pass here... so it's a cost that applies everywhere. given this can you see how the "dark rect" is almost a "zero" when considering performance here? :) btw the above - is not actually explicitly what is done - i'm breaking it down int what actually gets done by the canvas with the canvas objects/states set up the way they are by enlightenment. e doesn\t directly run rendering in its own code - it just sets up the scene and lets evas take care of figuring out how to render this. 14. in the flat theme in winlist.edc is a commented out section for a part that overlays the screen below winlist and "captures the rendered output of what is below" and applies a blur filter to it. it actually increases the blur size as it fades in and decreases as it fades out. it also has a darkened rect above. this leads to a very pleasing blurred background, but i found on my i5-4200u ... it couldn't keep up 60fps and it dropped to about 20-30fps. keep in mind that this capture + filter is LIVE like the miniatures. if you are playing a video in a window or hell even as a wallpaper, you will see the blurred effect renderer blurred updates of these changes as they happen. no cheating happened here - no "capture a still then never update it". it's full pipeline correctness. if you really want to you could try enabling this in the theme just to see the pain a gpu goes through. software rendering can do this too.. it's just even more pain. 15. in large mode there is a "figure out a layout for the windows" phase where it tries a whole lot of layouts to try nicely size the windows optimally. this actually is rather costly and can take some time. i did work on optimizing this, but with a lot of windows to display it can lead to s small judder at the start before things animate as e figures this out. i did cut it down from the original code for sure a while back, but a sufficiently slow machine might get a small judder you can see. 16. reality is 99% of your issue in list mode is the window miniatures. it gets exacerbated by a costly dither mode and will scale up in cost based on number and size of window miniatures in that list. the more pixels worth of these to render, the worse it will get. i'll add an option to disable these and then when i push that you can toggle and and see just how much difference that makes i do the above as an "education exercise". it' is not meant to make you feel stupid - i don't expect 99.999% of users to know the above. if i share, maybe 1% will know it and my life will be better in getting better feedback/reports :) it's incredibly hard to try and figure out what to ask to try and work out what is going on. when i read "blurry background" i know i had this in a prior stab at flat in the flat theme branch and i knew that was very costly, so that was my first port of call. so i hope the above helps explain a lot of things and put in place some building blocks of information to better work things out. :) > On 4/4/21 5:02 PM, Francesc Guasch wrote: > > On 04/04/2021 05:09, Carsten Haitzler wrote: > >> On Sun, 4 Apr 2021 10:20:15 +0900 Florian Schaefer <list...@netego.de> > >> said: > >> > >>> On 4/4/21 5:52 AM, Carsten Haitzler wrote: > >>>> On Sat, 3 Apr 2021 17:55:23 +0200 Francesc Guasch > >>>> <fran...@telecos.upc.edu> > >>>> said: > >>>> > >>>>> Hi. I am running Enlightenment 0.24.99 24520. > >>>>> > >>>>> It has always run smooth on my lapton, this is a 2005 Toshiba > >>>>> with 4 GB RAM. It sports an Intel Corporation Mobile GM965/GL960 > >>>>> Integrated Graphics Controller. > >>>>> > >>>>> I know I am pushing the limit here, sorry for that. Since the last > >>>>> release changing windows with ALT-TAB takes 2 / 3 seconds. After the > >>>>> window changes the list of tasks is shown and the back desktop is > >>>>> blurred for a few seconds. Then the selected window is shown and I can > >>>>> use it. > >>>> > >>>> how is it blurred. the default theme does not blur the background. i > >>>> tried > >>>> that a while back in flat but testing on an older machine showed it > >>>> could > >>>> not keep up (a 2010 intel laptop with intel gpu) and dropped to like > >>>> 20-30fps, so i disabled the filter and it just darkens what is > >>>> below... so > >>>> what you describe must be an altered theme? > >>> > >>> Sorry if I barge in into the discussion here. Just yesterday I also > >>> updated after some weeks again to he current git versions, now with the > >>> flat theme, and experienced the same "issue". (BTW, I also ran into the > >>> elput issue and had a jolly time figuring out that I need to enable the > >>> DRM option.) > >>> > >>> I guess what Francesc intended was exactly this fading to a darker > >>> background. On my machine here (i7-3517U) it takes probably about a > >>> second. But it is no smooth transition and rather seems to be stuttering > >>> along the way, thus feeling really as if the machine is struggling to > >>> keep up with rendering this transition. The effect is that the whole > >>> process of switching windows feels very sluggish and seems to take ages. > >>> > >>> I was also (unsuccessfully) looking around for a way to switch off this > >>> transition effect. Switching between windows with Alt-Tab is a very > >>> common action and I would like this to be over in literally in the blink > >>> of an eye. One can actually quickly switch windows in the current state, > >>> cutting the whole transition short right at the start. Still, I would > >>> prefer if I can have the window list either appear instantaneously or > >>> with a really fast fade-in and -out. > >>> > >>> (BTW, this is using the window switcher in list mode, not in large mode > >>> where this whole background darkening is probably really necessary as > >>> there is otherwise no window to separate the list from the normal > >>> desktop.) > >>> > > > > Maybe I didn't explain good enough. I reproduce it pressing ALT-TAB > > while I have some windows open. I don't know about window siwtcher in > > list mode or large mode that Florian talked about. > > > >>> Cheers and thanks as always for the great work, > >>> Florian > >> > >> also a large number of maximized windows (a lot of pixels to render) > >> will slow > >> down even the best of gpu's if you have enough of them... smaller windows > >> render faster in miniature (the input window is smaller). and both the > >> old list > >> mode and large mode how show these miniatures and thus render > >> everything you > >> see which costs.. the more you have visible, the more it costs. it > >> costs even > >> more in software rendering than a gpu... the "i dont even see the fade > >> animation" hints to me it's software compositing or a very large > >> number of > >> large windows. > >> > > Hey ! Thanks for stepping in Florian. I was wrong, the problem was not > > on the fading of the background, but on the app windows. > > I too built with the latest git commits but it didn't fix it for me. > > Is it running faster ? Maybe, I am not sure, but it is still slow. > > > > Right now I have a couple of Thunderbird windows and a Terminology > > and it is paifull. Probably because of the large Thunderbird window > > that takes all the screen. xrandr shows 1680x1050 60.00* > > > > Just to summarize: > > > > - Large Windows: yes, it gets worse with those. But just a gvim and > > a terminology also is noticeable slow. > > - Composite: OpenGL > > . glxinfo: direct rendering: Yes > > > > And now what may be the root of the problem: Turning rendering to > > software or opengl won't make a change. So the conclusion may be this > > laptop is way too old. I tried if I could download drivers but the > > Ubuntu software tool won't show any. With lsmod I see i915. > > I guess 2020 Enlightenment task switch was way faster because it > > probably didn't have this transition. > > I actually made the same observation, software rendering and openGL > won't make a difference. I thought this odd at that time. However, now > that we know its the previews and not the transition effect, it probably > makes sense. Seen that Raster has some dithering algorithm doing the > down-scaling its probably down to the CPU to do this. The way you put > the result on the screen, software or openGL, won't affect the time > required then. At least that's my understanding now. > > On a different note: I am a bit worried about this "laptop is way too > old" feeling. For me one of the selling points of linux in general and > also E in particular was and is that it is supposed to also run fine on > non-bleeding edge hardware. I am all in for fancy effects where the > hardware is capable of doing it but I hope to at least have the options > somewhere to cut back on the eye-candy and convenience functions (like, > e.g. real-time preview thumbnails) so that the system is still fun to > use on less capable computers. > > Anyway, still a happy user here who is thankful for all the effort of > the developers to provide us with a system that I can use both at work > and at home for well over a decade now. :-) > > Cheers, > Florian > > > I really appreciate you took the time to look at this and try an > > optimization just for us. Thanks a lot ! > > > > > > _______________________________________________ > > enlightenment-users mailing list > > enlightenment-users@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/enlightenment-users > > > _______________________________________________ > enlightenment-users mailing list > enlightenment-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-users -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- Carsten Haitzler - ras...@rasterman.com _______________________________________________ enlightenment-users mailing list enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users
