The Lounge - CodeProject

Re: I never liked writing graphics libraries

Rick York11-Mar-21 11:00

Rick York

11-Mar-21 11:00

I've always liked doing that. Cool | :cool:

What I don't like is programming in a straight-jacket, as you seem to be. I work with CUDA these days and it definitely has its limitations but not nearly as severe as your little things do. My limitations are things like, I only have 8GB of VRAM and 2304 cores to work with - how am I ever going to make it fit? Luckily, my answer is buy a better card if we have to. You don't seem to have that option available, unfortunately.

"They have a consciousness, they have a life, they have a soul! Damn you! Let the rabbits wear glasses! Save our brothers! Can I get an amen?"

Re: I never liked writing graphics libraries

honey the codewitch12-Mar-21 3:38

honey the codewitch

12-Mar-21 3:38

Coding with no RAM builds character! Laugh | :laugh:

Real programmers use butterflies

Re: I never liked writing graphics libraries

Rick York12-Mar-21 6:15

Rick York

12-Mar-21 6:15

Yes, but it's a bit too masochistic for my tastes.

"They have a consciousness, they have a life, they have a soul! Damn you! Let the rabbits wear glasses! Save our brothers! Can I get an amen?"

Re: I never liked writing graphics libraries

honey the codewitch12-Mar-21 8:22

honey the codewitch

12-Mar-21 8:22

I like the creativity it requires.

Here I get called back with rectangles I'm getting from "converting" a jpeg - in this case into a raw rgb565BE bitmap form, compatible with the frame buffer of the LCD display I'm using. I'm them telling the device to do a DMA transfer from the ram I just gave it, in effect, loading the JPEG onto the display one rectangle at a time:

jpg_state js;
js.tft=&tft;
js.dma_space=dma_space;
js.size = dma_size;
io::file_stream inp("/spiffs/warhol320x240.jpg",file_mode::read);    
jpeg::convert(
    inp,
    [](const rect16& rect,size16 size,const rgb888* bitmap, const void* state){
        jpg_state s = *((jpg_state*)state);
        const rgb888* end = bitmap+(sizeof(rgb888)*rect.width()*rect.height());
        assert((((end-bitmap)/sizeof(rgb888))*sizeof(rgb565))<=s.size);
        uint16_t* buf=(uint16_t*)s.dma_space;
        while(bitmap!=end) {
            rgb565 col = color::reduce(*bitmap++);
            *(buf++)=env::platform::mkbe(col.value);
        }
        return result::success==s.tft->write(rect,s.dma_space);
    },
    &js);

Real programmers use butterflies

Re: I never liked writing graphics libraries

Daniel Pfeffer11-Mar-21 22:21

Daniel Pfeffer

11-Mar-21 22:21

Many moons ago (Before Windows), I wrote graphics packages for the CGA, EGA, and Hercules. These ran on the IBM PC (640KB, 8088at 4.77 MHz) with reasonable performance. This, despite arcane addressing and slow I/O.

Even if I/O is slow, how difficult could it be to write graphics packages for a 32-bit processor with tons (8 mega bytes!) of memory?

Without going into details, perhaps you're over-engineering the problem. For example, unless there is a specific requirement for supporting JPEG images in runtime, why not convert them offline to a more amenable format? I am certain that many other shortcuts are possible if you think of the problems in the right way.

Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.

Re: I never liked writing graphics libraries

honey the codewitch12-Mar-21 3:29

honey the codewitch

12-Mar-21 3:29

Daniel Pfeffer wrote:
For example, unless there is a specific requirement for supporting JPEG images in runtime, why not convert them offline to a more amenable format?

I thought about it. But then I remembered that 320*240*16 is a really big number, and my flash storage size isn't a much bigger number, even on the ESP32 which is fairly generous.

But actually, that's not the main reason I support it. I support it because SD cards and cameras exist for these monsters and both typically can produce or source pictures or frames in JPEG format

I wrote the JPEG library. I have andy warhols sunglassed face starting at me from inside the ESP32 Wrover Kit's LCD and rippling weirdly under the effect I'm running right now.

If it makes you feel any better, I thought about supporting PNG too, before catching myself.

Real programmers use butterflies

Re: I never liked writing graphics libraries

Gary R. Wheeler12-Mar-21 10:35

Gary R. Wheeler

12-Mar-21 10:35

honey the codewitch wrote:
I love coding for these little things because you're so close to the metal, but when you want to go your own way with something, because existing offerings are too heavy or limited, you have to start over from scratch.

Something about cake and eating it too comes to mind Big Grin | :-D

.

I've implemented a couple graphics libraries in my time. Instead of run-time polymorphism, try build-time polymorphism. Instead of a device 'driver' that has to be all things to all people, have a device-specific bottom layer with an interface that's sufficiently generic for the graphics library's purposes, but no more than that. This device layer provides only essential primitives: line drawing, curve drawing if you need it, region fills, essentially only the device coordinate primitives you might want. A lot of Bresenham's algorithms are useful here. I've not implemented significant text capabilities, but there are primitive operations for that the device layer can provide (draw a block of pixels, for example). Since footprint is a concern, the device layer should be granular in a way that lets the linker prune parts that aren't used.

Needless to say, K.I.S.S. should be your guide here.

Software Zen: delete this;

Re: I never liked writing graphics libraries

honey the codewitch12-Mar-21 10:46

honey the codewitch

12-Mar-21 10:46

I'm on the fence about using templates for that. flash program space is almost more valuable than RAM so templates are problematic because of the code bloat they tend to introduce. I'm not fully opposed to them in this case, and i've used one or two little ones (mainly for templating a piece of hardware's physical pin assignments) but I haven't been doing any generic programming as a rule.

The driver does exactly what you're talking about. And the challenge is coming up with something high level enough that it satisfies the better devices in terms of being able to use their hardware features like line drawing, without incurring a bunch of overhead for most drivers that don't have it and typically just deal in bltting.

My attempted approach right now is to build the fundamentals into the library such that the compiler and linker can eliminate what's not used - for example, if your hardware supports line drawing the software won't link the line drawing code into the library.

I'm doing this by creating static helpers that do basic drawing. The drivers call the hardware or return a not_supported result. If it's not supported, a canvas can fallback on using the software, at which point it will be included in the final source.

This is tricky. The other thing I'm running into is if I expose a canvas from a given bitmap, then I have to support any graphics features used by that canvas in software, since no video card is involved, leading to potential inclusion of much of the library under many situations. =(

Real programmers use butterflies

Start baking a pie

Cp-Coder11-Mar-21 4:54

Cp-Coder

11-Mar-21 4:54

March 14 (3-14) is national pi day!

Get me coffee and no one gets hurt!

Welcome to the Lounge