OSDev.org

I'm pretty far from writing a real GUI for my OS, but I had an idea related to it. The UTF-8 format, afaik from the Wikipedia article, has two different values for the first byte that are not defined: 0xFE and 0xFF (the others are either ASCII, determine the character type, or are reserved). 0xFF is obviously the better one for error checking, because it maps to -1.

What if you extended UTF-8 via this extra byte pattern (0xFE) to include not only character symbols but also symbols that represented raster or vector graphics? Each multibyte symbol starting with 0xFE could be a pixel or line or graphical control character. Character cell and pixel graphics could coexist in the same window, and pipes could transmit both text and graphics - think of what you could do with a command line image editor. The graphics driver could (in addition to a buffer-style interface) accept these streams directly.

Does anyone see a practical problem with doing this? Or a suggestion?

Thanks!

More a bit for the encoding overhead. Having to marshal drawing operations in variable-length structures complicates things. You'll notice it when you try to push lots of data over a communications channel of any sorts.

I do something close to the inverse: I communicate according to GLX with graphics drivers, and map anything non-3d into opengl extensions. Like one of those optimisation one-liner reads: "do not aggravate the worst case".

$.02

I think thats a neat idea.. I'm sure if you combine every UTF namespace out there, there is 4096 unique combinations([8*8]^2 which represents every dot combination in a 8x8 character).. but having it actually defined would be rather neat..

That would mean that each UTF character would need to be 3 bytes(if you want to not deal with variable size "pixels")... I say it's feasible, although probably a bit slow

earlz wrote:I think thats a neat idea.. I'm sure if you combine every UTF namespace out there, there is 4096 unique combinations([8*8]^2 which represents every dot combination in a 8x8 character).. but having it actually defined would be rather neat..

I think you misunderstood - each character would be a pixel at a position, not a glyph that is a combination of pixels. You could go from writing text after the cursor to plotting points at exact coordinates without changing any sort of mode or finding a character that matches that pixel pattern. Afaik, Unicode has plenty of character-cell graphics characters already.

@Combuster: If it was implemented naively, I can definitely see performance problems. But, I think there are a lot of optimizations that could be done to make it much faster. First, simple vector graphics primitives (lines, maybe Bezier curves) would be a must, and maybe even better than using a buffer if the graphics driver had 2D "acceleration". Second, there could be symbols that mark the beginning of a large section of raw pixels without any special encoding, which would remove the overhead of marshaling every single pixel or other primitive. I'm not intending this to be the only way of doing graphics, but instead the only way of anonymously transferring graphics between programs using pipes; where speed is a concern, a graphics driver could read straight from a buffer.

I don't really see the advantage of doing this from having some lead byte that says "here comes the text" and another one saying "here comes the graphics". Marshalling stuff is relatively trivial. Do what you like there :).


JAL