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

[Eero Tamminen <oak@xxxxxxxxxxxxxx>]

This is a multi-part message in MIME format.

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.

GPU HW is designed so that you don't get perf
impact from basic filtering.

=> there should be a performance impact only if
   SDL picks up GL(ES) / Direct3D backend, which
   happens to be software implementation...

That should be very rare, and user can override
the backend with SDL env variable if it's
a problem.


> Maybe we should not care about such old systems anymore, but I think
> that's rather something that we should revisit after the next release
> has been done, and not do it now before the upcoming release.
>
> > > they should change the RenderQuality setting manually instead.
> >
> > In that case, there should be at least command
> > line option for it, so that user can set it
> > along with the zoom option.
> >
> > I'm OK either way.
>
> Thinking about this for a while, I guess the automatic way is likely
> better than adding more config options (we've got too many of those
> already anyway)...

As it doesn't have effect with all the SDL
backends, it being user-visible setting is
less desirable.


> but let's wait for the next release first. I think
> after the release, we should do a major clean-up and also remove SDL1
> support (SDL1 is decomissioned since more than 6 years now, so
> everybody should now really use SDL2 these days).

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.


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...


> > 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.


> maybe another thing to clean up after the next release...

Sounds like a plan, should I add these to deprecation list?


	- Eero