[haiku-development] Re: Disable BView antialiasing

  • From: Caitlin Shaw <rogueeve@xxxxxxxxxxxxx>
  • To: haiku-development@xxxxxxxxxxxxx
  • Date: Fri, 25 Sep 2009 12:31:58 -0700

And what would that add exactly? We have already established that most
of the apps don't care about being anti-aliased or not. It is just for
those apps that do some customized drawing that rely on a certain

Your argument 'it only affects diagonal lines and circles' really
works both ways here. There are very few apps that use these
primitives, so in the same idea we can just accept that we break
those, while keeping the majority of apps working.

You are right.

But let's also consider how the on/off switch is implemented (and ignore the stuff about the runtime_loader for now). It seems to me that this will be either a bitmask flag--perhaps passed in the view constructor, along with such things as B_WILL_DRAW--or a function call, to join the likes of SetLineMode().

If the flag is on by default:

- If it is a bitflag, then a new constant for the flag is added to the .h files. All old programs and source work exactly as they did when they were written. If you want to, you can activate a flag and make them look a little better. The source won't compile anymore on R5, but you're specifically asking for new Haiku features, so you shouldn't expect it to. The binary probably will still work though, since that bit was previously reserved.

- If it's a function, then all old code works just as it did, but you can call that function if you like. If you do the program won't run anymore at all on R5, but you specifically asked for new Haiku features anyway.

If the flag is off by default:

- If it's a bitflag, then you will need to learn about the flag and update your old source files before you can get them building properly on Haiku. After the update, the source won't compile anymore on R5, although everything still looks the same. If you're willing to do some refactoring, you can get your old code "updated" to be able to handle AA, and then it will be able to compile on both. Either way, the binaries produced will probably run on either.

- If a function, then the same goes if you're willing to refactor, but if not you have to pick R5 or Haiku, because it will only run on one or the other, although it doesn't look any better on Haiku.

This is the list of possibilities I went down in my head. Based on this, it seems that the simplest and best way is the first way, a bitmask with default=off. That naturally solves the problem and is both backwards and forwards compatible, whereas the other idea is to change the API behavior, then oops that broke a couple of things, so we'll add a flag to change it back, but oops we can't recompile some of those apps to add the flag, so we'll hack the runtime loader to detect that fact and add the flag for them.

I realize that none of these are that big of a deal, but all things being more-or-less equal, I start looking at scuttleties.

If you are not going to argue this point, I will not respond.

Well it seems that most people would prefer default=on, and so being in the minority, and a relative newcomer to the scene, plus not having much of a preference myself, it's probably best I don't hold things up over this point if everyone else is agreed. I don't actually care, it's just that thinking about it logically, I come to the conclusion for several reasons that default=off is the right way to do it. My interest in which is default is really how the side-effects affect the experience on Haiku; I want Haiku to be as "good" as possible; whether I have to pass a 1 or a 0 when initializing my views is trivial.

Other related posts: