[haiku-development] Re: Disable BView antialiasing
- From: Niels Reedijk <niels.reedijk@xxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Fri, 25 Sep 2009 15:25:30 +0200
Hello Stuart,
2009/9/25 Stuart Adam <engaric@xxxxxxxxxxx>:
>
>
>> 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?
It is not complex and it is already done in for example the network
libraries (albeit with different semantics). Apps compiled for Haiku
have a signature in the binary which can be checked. Any
BeOS/Dano/bone app does not have that signature and can be recognised
by that.
>> > 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.
If BeOS applications are by default non-AA, they will not exhibit the
problems and as such technically minded testers will not have to
intervene anyway. If it is a problem in a Haiku app, it is a bug and
therefore it should go the the developer rather than the tester.
>>
>> > 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
> propose.
Either your app works perfectly with AA enabled, or your drawing is
messed up and you check the Haiku Book and it talks about AA and you
know how to disable that.
Now in the first case it is not additional work at all, and in the
second it is part of the development process.
>> > 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.
I recall most of this thread was about a technical sollution rather a
list of all the apps that are having issues. I recall two specific
apps being discussed. Even if there are more, it does not influence
the argument a lot, since I am opposing your sollution on technical
and philosophical grounds anyway ;-).
>> This is a classical case of over-engineering. Keep it simple!
>
> 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.
Your flag design involves three layers of the code:
a) The interface kit layer which needs to be rewritten to support
non-AA drawing.
b) The FileTypes app which you want to make aware of this flag
c) The website and build system that need to be adapted to produce
such an automation.
The detection routine is far simpler, since it only involves level a.
I cannot imagine that detecting the platform of the image is difficult
(though I would like a second opinion by someone in the know of the
elf layer). Furthermore, the API call you are referring to is merely a
flag that can be fed to the BView constructor (per stippi's mails).
> 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 heuristic is not that complex (though second opinion welcome).
Furthermore, BView has to be rewritten to support non-AA drawing
anyway (no matter what sollution you are implementing). Internally
this will probably work with a flag. It takes little effort to expose
that flag to the developer.
Finally, you are forgetting that the 'simple fs attribute check'
involves a more complex attribute setting routine. Especially
developers that are writing an application recompile their code often,
and every time they would have to reset that flag.
> 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.
And you still have not been able to convince me why any user should
know about the AA vs. non-AA difference, and more importantly, why
they should be able to influence this. The problem is a
developer-problem, they decide how their software works and they
decide how it is presented.
But feel free to convince me though :-)
N>
Other related posts:
