Magnify quits

[meanwhile]

Magnify quits within 0.5 seconds...and without error messages. (tested on hrev25229)

[meanwhile]

Using both lower resolution and less colours Magnify can run, though the cursor stays visible :S (using the same computer/graphics card as in -probably related- bug #2057).

[meanwhile]

When switching back to original screen settings I find out that only at the very first change in resolution (of a fresh new revision, for example) I can choose the highest setting. This probably isn't 32 bits/pixel at all, and later on the OS rightly tells me so (see 'screenmode.png').

[meanwhile]

Aplologies for the double attachment...

[mmlr]

If you run Magnify from the Terminal it will tell you that it was run in an unsupported colorspace. This is because Haiku will pick up higher bit depth VESA modes now which will lead to 24bit being selected (if available) instead of 16bit. Axel did some changes so 24bit modes are advertised as 32bit AFAIR. This is more or less "correct" as it doesn't really matter whether you are using 24bits or 32bits in the frame buffer, as you never have an alpha channel in the frame buffer anyway which makes 32bits modes simply waste a byte per pixel with the same result as if you were running 24bits. But for functions that draw directly into the frame buffer (BDirectWindow -> Chart for example will run incorrectly in 24bit mode too) or apps that grab parts of the frame buffer like Magnify does, they need to be aware of the difference in 24bit vs. 32bit mode and need to support each mode individually. Also the preflets should obviously support it.

[axeld]

Not sure what you mean by "the preflets should obviously support it". What I did was that the "Screen" preferences application does not show you 24-bit, it will always show you 32-bit - for the user, there is no difference, so they don't really have to care. So all we have to do is to add 24-bit support to Magnify in order to let it run on certain VESA systems (most use 32 bit, anyway).

[mmlr]

Ah, it was only in the Screen prefs. I thought the change was done on a lower level and the Screen prefs would therefore display as 32bits. Anyway the Screen preferences is what I meant where it should be supported, but in this case that's already behaving as expected.

So yes, support for 24bit color spaces should be added to Magnify and Chart. I assume though that BeOS did never use 24bits and that's why those apps do not support the color space? If this is the case, for BDirectWindow/BWindowScreen cases this could lead to problems in the future though. I could imagine that for example games do not support 24bits either if BeOS never used them. Then the user could get pretty confused when Screen states 32bits which is expected to work, but in fact it is only 24bits and causes the app to fail (at least I would be a bit confused).

Generally I find it a bit questionable to advertise 32bits if it really is 24bits. I mean it does not hurt the user if it states 24bits, but it could cause a bit of confusion if it states 32bits when it really isn't. Not that it would matter to the user directly, but it does matter to applications (as they have to support that color space).

[axeld]

I remember I had a specific reason why I did it this way. However, I don't remember now anymore :-) In any case, I tend to agree with you that showing the actual number of bits is the better idea.

[axeld]

Fixed in hrev25272.

[meanwhile]

Okay, the bug is now gone in as far as that I know my computer handles 1024x768 & 16 bits/pixel as maximum and that this setting should be chosen. However, when first booting a new revision the screen preference window wrongly shows the 640x480 & 32 bits/pixel option not greyed out and even marked. After applying 1024x768 & 16 bits/pixel, closing the screen prefs window and reopening it, the seemingly more ideal choice of 1024x768 & 32 bits/pixel isn't greyed out, can be chosen, but then the error message from the attached screenshot shows up.

[axeld]

What does this have to do with the original bug description? Nothing! I you have any *other* problems, then please put them into *another* bug, but not here, that's just confusing.