Re: [hatari-devel] Suggested patch to fix the SDL GUI on KMS/DRM

[Thomas Huth <th.huth@xxxxxxxxx>]

Am Sat, 31 Oct 2020 09:11:08 +0100
schrieb Nicolas Pomarède <npomarede@xxxxxxxxxxxx>:

> Le 31/10/2020 à 08:55, Thomas Huth a écrit :
> > Am Sat, 31 Oct 2020 08:49:39 +0100
> > schrieb Thomas Huth <th.huth@xxxxxxxxx>:
> >   
> >> Am Sat, 31 Oct 2020 07:55:28 +0100
> >> schrieb Jens Guenther <dbotw@xxxxxxx>:
> >>  
> >>> Hi,
> >>>
> >>> while discussing an issue with the Tandy TRS-80 emulator SDL2TRS
> >>> in the RetroPie-Forum (1) regarding KMS/DRM with SDL2 on the
> >>> Raspberry Pi 4 and Wayland, it turns out that the patch also
> >>> fixes it for Hatari ...  
> >>
> >> Interesting ... we removed that call three years ago, after
> >> deciding that it is not necessary, see:
> >>
> >>   https://git.tuxfamily.org/hatari/hatari.git/commit/?id=5a59019da3e
> >>
> >> and the related discussion:
> >>
> >>   https://listengine.tuxfamily.org/lists.tuxfamily.org/hatari-devel/2017/02/msg00144.html
> >>
> >> Why is the call necessary with KMS/DRM and Wayland? Does it have
> >> any side effects there beside clearing the surface?
> >>
> >> So in case we have to include this again, do we have to do it on
> >> each frame? Or would it be ok to only call it e.g. only on every
> >> 50th frame to avoid the speed penality of the unnecessary screen
> >> clear?  
> > 
> > Ok, I've found some more information here:
> > 
> > https://wiki.libsdl.org/SDL_RenderPresent
> > 
> > Citing: "You are strongly encouraged to call SDL_RenderClear() to
> > initialize the backbuffer before starting each new frame's drawing,
> > even if you plan to overwrite every pixel."
> > 
> > ... so I assume we should simply add the SDL_RenderClear() again,
> > to be on the safe side? Nicolas, what do you think?  
> 
> Hi
> 
> I'm not an expert with this, but if the docs state to do it and we
> don't see any immediate regression, then I think we should include it
> before release (especially if it can improve wayland usage, which is
> used more lately with Gnome desktop)  (I don't use wayland myself to
> test it)

I've now added a slightly more complex patch which only calls this
function if hardware accelerated rendering is used. So with software
rendering, we can still spare these cycles, and with hardware rendering
it should not matter too much from a performance point of view anyway,
so we should be on the safe side here now.

 Thomas