[haiku-development] Re: Disable BView antialiasing
- From: Niels Reedijk <niels.reedijk@xxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Fri, 25 Sep 2009 14:32:59 +0200
Hi Stuart,
2009/9/25 Stuart Adam <engaric@xxxxxxxxxxx>
>
> > +1 on the flag instead of a new function set. I gotta say though this
> > kind of thing being talked about above sounds like the kinds of hacks MS
> > put into Windows to keep old 3.1 software working. I say lets find a way
> > to keep the behavior consistent, do it right the first time and avoid
> > loading down Haiku with weirdness like that that could stick around for
> > who knows how long. I don't actually really have a preference whether
> > it's on or off by default. Obviously off by default is better for the
> > stated goal of compatibility with R5, whereas on by default may be
> > better for the future. I guess it just depends which one is more important.
> >
> > I can see myself using both on and off modes in new software, so I would
> > not say it's only a concern about compatibility. But I agree that we can
> > not necessarily expect old apps to be recompilable. Besides that, "all
> > you have to do is add one line and recompile", isn't technically "binary
> > compatibility". Does that matter? I don't know. If it's decided not, I
> > would say that in that case the implementation should be such that
> > whatever is done to turn the flag off is a no-op on R5. Otherwise, the
> > updated app might not link anymore on it's original platform, and there
> > would have to be two versions of it.
> >
> >
>
> I would suggest a central registry of applications with known issues with AA
> which could be held on the Haiku site.
> A copy of this list could be packaged into the installed at build time and
> applied to applications as a bfs attribute.
> A preflet could be supplied to fetch an updated copy of the list and auto
> apply to all installations of listed applications an advanced mode could be
> supplied to offer a checklist of applications to apply the attribute to.
> On the file info panel of applications this flag could be editable.
I am sorry, but this is overengineering for something that at this
point seems to be a limited problem. The sollution Stephan gave should
be enough, Haiku applications can turn anti-aliasing off at BView
level and BeOS applications are not anti-aliased at all.
(Though I fear that that might create a clear visual distinction
between Haiku apps and BeOS apps).
> The advantages of doing this as an attribute are as follows :-
> 1) can be easily applied to applications to which we do not have source code
> access
Which is the same if we make BeOS-compiled apps non-AA by default.
> 2) easily switchable for evaluation of AA issues
Which is the same if a developer switches it on or off during the
development process.
> 3) does not introduce a new api call which could cause haiku designed
> applications to be incompatible with beos
Those who at this point still want to make Haiku apps available for
BeOS (which I imagine are very few people) can simply put an #ifdef in
the code. Really, re-engineering the app server/interface kit in such
a complex way in order to avoid an ifdef ... no!
> 4) if a mechanism is found to make AA compatible with B_OP_INVERT erasure the
> compatibility can be easily removed from app_server and the flag removed
Yes, or the developers are notified about this change and they adapt their app.
> 5) compatibility modes and compatibility database easily visible unlike
> Window's shim database
Visible, but who would use it? As far as your email goes, only
developers that have their source code on Haiku anyway. Keeping the
list might sound like a good way to avoid BeOS apps to look dated if
it is not necessary to non-AA them, but who is going to make that
list? Are _you_ going to check all the software? and what if someone
runs into issues with old apps, but does not have the knowledge about
the existence of AA-problems...
This is a classical case of over-engineering. Keep it simple!
N>
Other related posts:
