[haiku-development] Re: Disable BView antialiasing

  • From: Stuart Adam <engaric@xxxxxxxxxxx>
  • To: Haiku Development <haiku-development@xxxxxxxxxxxxx>
  • Date: Fri, 25 Sep 2009 12:57:35 +0000

> Date: Fri, 25 Sep 2009 14:32:59 +0200
> Subject: [haiku-development] Re: Disable BView antialiasing
> From: niels.reedijk@xxxxxxxxx
> To: haiku-development@xxxxxxxxxxxxx
> 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.

How will this be detected? Some complex load time heuristic?

> > 2) easily switchable for evaluation of AA issues
> Which is the same if a developer switches it on or off during the
> development process.

Can only be done by the developer not technically minded testers and the 
community does not always have code access to applications of interest.

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

So additional work for each additional developer vs a simple check in the OS 
which is still required at some level via whatever switching machanism you 

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

Exactly.  There is no significant cost to this either way.

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

No I am not intending to check every app myself but that is the advantage of an 
open source community I would be quite prepared to check apps which I myself 
use.  At the moment the Haiku project at Alpha is still rather developer facing 
so yes I would expect to find people who care.  If there weren't this thread 
wouldn't already be this long.
> This is a classical case of over-engineering. Keep it simple!
> N>

Sorry cannot agree that this is over-engineering.
The design for detecting the flag is simpler than auto detect of app style and 
no more complex than having to add a new api call.
The app_server needs the swithcable behaviour anyway even with the other two 
proposed ways of handling this of setting it via api call or via inspection of 
apps as being BeOS rather than Haiku based.  

This avoids having to write a complicated heuristic which can distinguish 
between a) BeOS apps b) Haiku apps c) Haiku apps which want BeOS like 
behaviour.  I for one would not want to write that code but a simple fs 
attribute check would be easy.

The only complicated work would be the installer/preflet options.  That would 
not be neccesary imeadiately to enable the feature it would simply be a case of 
applying a Be Inc style attention to detail to make managing settings simple.  

Stuart Adam

With Windows Live, you can organise, edit, and share your photos.

Other related posts: