Brendan wrote:
You may have several computers where you are unable to use graphics mode for various reasons; but nobody else has any computers where everyone else can't use graphics mode/s. I suggest the problem may not be related to hardware or firmware.
More specifically, I'd suggest that your problems are either caused by bugs in your virtual8086 support, or caused by a failure to provide adequate device independence (e.g. an application that is "hard coded" for a specific video mode that fails when that specific video mode isn't available); and in both cases a sane design wouldn't have had any problems to begin with.
That's correct. Most of them are related to VBE. However, on UEFI, they might just as well be related to the graphics system not being able to draw pixels because of unknown video mode organizations. With VBE, you can filter out unwanted video-modes in the driver based on what the driver knows about. This is not the case for UEFI, which potentially could require a native video-driver, but since the boot loader doesn't (and shouldn't) know which driver support is available, it would have to setup some mode and hope it could be used.
Brendan wrote:
Because your code is bad, or because you think it's impossible to setup any graphics mode during boot on some systems?
I don't think it is impossible, rather unwanted and a bad practice.
Brendan wrote:
Um, what? Obviously the compiler would continue running and the performance monitor would continue collecting data - you just wouldn't bother wasting CPU time to generate video data that will never be seen. If/when the performance monitor actually becomes visible, then you spend CPU time drawing the previous "list of commands" that it sent (not before).
The previous list of commands was 10,000,000 lines of text that were generated during 12 hours, and all but the last 25 lines have been scrolled-off the display. Your switcher will spend minutes or hours in scrolling text that the user cannot read and ending up with 25 lines of visible text. How user-friendly and effective is that?
Brendan wrote:
You only keep the most recent list of commands, not every list of commands that the application created since the dawn of time.
Not possible
Example:
Code: Select all
DrawText(0, 0, "my app")
DrawText(10, 0, "2013-07-27 09.00.00")
DrawText(10, 0, "2013-07-27 09.00.01")
DrawText(10, 0, "2013-07-27 09.00.02")
DrawText(10, 0, "2013-07-27 09.00.03")
DrawText(10, 0, "2013-07-27 09.00.04")
DrawText(10, 0, "2013-07-27 09.00.05")
...
Your code determines (after some time) that DrawText("my app") is no longer recent, so throws it away and now you only see the clock, not the name of the app.
Brendan wrote:
The normal approach is to pre-load the huge PNG file into a texture with one command, and once it's loaded into a texture you can display it with a single command as many times as you like. For the pre-loading, I'd tell the video driver which file name and let the video driver load the file itself. Sadly other systems (e.g. OpenGL) don't work like that and the application would have to load the file and then transfer the data (which is extra work).
My PNG-loader creates a memory-based bitmap which is then blitted to the display. Bitmaps are referred to with handles and thus doesn't send pixel data when referred to. The physical display is also a bitmap, as is a printout on a printer. All graphics primitives operates on bitmaps and gives the application an uniform interface independent of type of bitmap (memory, display, printer) and memory organization.
Brendan wrote:
Of course for most things (e.g. icons, menus, fonts, etc) you'd want to use scalable/vector graphics rather than pixel data.
You don't want to have icons or menus in you graphics API at all. These are things that should be constructed at a higher level when needed only. For fonts, you want to have a TrueType font renderer or similar.
Brendan wrote:
Here's a very simple multiple choice question. It's faster to:
- a) set thousands of pixels in a rectangle to "blue", then scale all those pixels, then rotate all those pixels 90 degrees, then blit the final result; or
b) describe the blue rectangle with "(x1, y1) (x2, y2) colour", scale and rotate the description at the same time (multiply co-ords by a matrix), then draw the final result
Hint: The correct answer is not "a)".
What does poor programming skills have to do with performance of a GUI?
Naturally all coordinate scaling is done before working on pixels. This is independent of working with commands or directly with LFB. Or do you think that the user program needs to use "plot" in order to fill a rectangle with blue? There are both ellipse and rectangle (filled and non-filled styles) primitives available.
