Re: [hatari-devel] Open Hatari in big window

[Thomas Huth <th.huth@xxxxxxxxx>]

Am Fri, 6 Mar 2020 01:17:17 +0200
schrieb Eero Tamminen <oak@xxxxxxxxxxxxxx>:

> Hi,
> 
> On 3/5/20 10:51 AM, Thomas Huth wrote:
> > Am Thu, 5 Mar 2020 01:54:32 +0200
> > schrieb Eero Tamminen <oak@xxxxxxxxxxxxxx>:
> >> On 3/3/20 8:25 AM, Thomas Huth wrote:
> >>> Am Mon, 2 Mar 2020 22:58:18 +0200
> >>> schrieb Eero Tamminen <oak@xxxxxxxxxxxxxx>:
> >>>> On 3/2/20 4:14 PM, Thomas Huth wrote:
> >>> I don't think that modifying RenderQuality automatically is such a
> >>> good idea here. That will only cause confusion e.g. when the users
> >>> have a look at their hatari.cfg afterwards and wonder why the
> >>> setting was changed...
> >>
> >> If it's set automatically to the best value,
> >> user option could be removed. :-)
> > 
> > I'm not sure whether automatic linear scaling is really always the
> > best value for everbody ... there might be a perfomance impact for
> > this on old systems, too?
> 
> According to SDL docs, that hint is used only with
> GL(ES) and Direct3D backends.

Ok.

> I added support for changing the quality automatically also on window 
> resizes, and
> fixed the logic to handle zoomed size being
> constrained e.g. by desktop size. See
> the attached patch.

Sorry, I currently do not have any spare time anymore to review patches
(I'll be travelling during the next weeks)... so if somebody else could
review this, that would be great.

> Should I add the quality command line option just
> for the release (and disable automatic setting), and remove quality / 
> linear scaling options after
> the release (and re-enable automatic setting)?
> 
> Not sure whether that makes sense...

No, just adding a command line option for just one release does not
make much sense. It's likely better to always do it automatically and
then to also remove the "linear scaling" option from the GUI.
Please check with Nicolas whether he still wants that before or rather
after the next release.

> >> Btw. Why there's an option for disabling
> >> SdlRenderer usage, is it e.g. because it needs
> >> working GLES support, and all platforms might
> >> not have that?
> > 
> > Yes, that was the original intention. Not sure whether we still need
> > this now in 2020 since every recent machine should have GL support
> > now...
> 
> There are some corner-cases where Mesa may
> fallback to GL SW implementation:
> - machines that have a display, but lack a real
>    GPU (e.g. some server machines at work still
>    used Matrox cards!)
> - HW is too new to have a working driver in
>    given distro
> - driver is proprietary, so distros don't ship it
> 
> I don't think we need to care about them.

I agree.

> > maybe another thing to clean up after the next release...
> 
> Sounds like a plan, should I add these to deprecation list?

Yes, please!

 Thomas