gdispGBlitArea() example

[JohnLKW]

Hi All

Is there any example on how to use gdispGBlitArea(GDisplay *g, coord_t x, ...) and where is it?

Is use Pixmap a precondition to use gdispGBlitArea()?

John

[Joel Bodenmann]

There's not really a dedicated example for this as you usually know what you're doing when you need that function.

gdispGBlitArea() doesn't require a pixmap. It is a standalone high-level API function. The parameters are explained in the API documentation.

Could you be more specific with your question? Are you facing an issue with it?

[JohnLKW]

I am thinking where to accommodate a framebuffer that is located in external graphic controller (like SSD1963) so that I call gdispGBlitArea(... const pixel_t *buffer) with *buffer point to that framebuffer.

There is a relevant post about this topic at

But I am not sure if there is some other way that does not need to change GDisplay structure...

I was considering Pixmap but it doesn't work for my controller because it is a SPI-based external controller that cannot map to addressable memory space for Pixmap.

This is what puzzling me...

[inmarket]

You are probably misunderstanding pixmap.

Pixmap provides a RAM based framebuffer of any specified size. It has no relation to your real display other than it uses the same pixel format.

A pixmap then can be treated as a framebuffer, a display and optionally as an image. When treated as a display you can draw on it using any of the normal gdisp calls. When treated as a framebuffer you can use it as the source parameter for gdispGBlit (to copy any portion of it to a real display or another pixmap). When treated as an image any of the gdispImage calls can use it as the image parameter.

So,

1. gdispGBlit does not require a pixmap - it only requires an array of pixels as the source. Pixmap can be used as one posdible source of those pixels.

2. Pixmaps don't care about the type of display you are using. They are RAM based.

3. If you want to get information off a display the ONLY way is to use the gdispGetPixel call. The only exception is a pixmap (which is not a real display) because pixmap has this ability to appear as a display, an array of pixels (a framebuffer) or as an image. There is no connection between the framebuffer a pixmap uses and the framebuffer of a real display controller.

[JohnLKW]

Yes, the concept of Pixmap is puzzling me especially when it doesn't fit for my case. Attached is a block diagram for your reference. The current problem is that, it is not possible to map the external SDRAM to a pixmap surface as it is not an addressable RAM space for the MCU. Small systems like a Teensy doesn't have sufficient RAM space for 1024x768 frame buffer. Since Pixmap doesn't work for me, I am now considering gdispGBlit().

Although it is possible to copy an array of pixels from the sd card  as the source to display, the performance is very slow. One will see pixel raster across the screen like snail walking.

An alternative is to copy the array from sd card to a buffer allocated in those unused 10pages external SDRAM (say page 2). Some mechanism to notify the system that copy is complete then a single instruction can be used to copy from page 2 to page 1 which is the physical display to solve tearing effect. a 2D blit function is available in the gfx controller for this, but I still have to decide where to declare a framebuffer in uGFX.

Similar topic by crteensy above have tackled this problem with a slight modification to GDisplay structure.

I am wondering if there is any native location in uGFX for this purpose instead of a change to GDisplay structure?

 

 

[inmarket]

If your display controller supports additional on chip RAM you can use special gdispControl commands to perform operations on that RAM. None of the existing uGFX drivers currently do that due to the code overhead and the time for us to implement it although there are some commercial projects that have written custom drivers to enable such features.

Note if you are trying to access that RAM in order to provide a type of tearing protection you will likely need a much more powerful processor than the teensy despite the accelerated operations provided by the controller.  The reason is that despite those operations there is still quite a lot of overhead that requires cpu intervention and adding any sort of double bufferring definitely increases the amount of drawing required.

[JohnLKW]

2 hours ago, inmarket said:

you can use special gdispControl commands to perform operations on that RAM. None of the existing uGFX drivers..

Does it mean that it is an internal routine not released in current uGFX version? Where to find more information about the "special gdispControl commands"?

2 hours ago, inmarket said:

Note if you are trying to access that RAM in order to provide a type of tearing protection you will likely need a much more powerful processor than the teensy...

If there is an apparent tearing I will try to use Vsync as the time gate to update any blit command. Hope this will solve tearing. But even though vsync is not used I think it would be better than showing pixel-by-pixel raster from Flash or SD card to display directly. Teensy is selected for its friendly audio library.

Edited June 9, 2017 by JohnLKW

[JohnLKW]

Found an interesting library that may solve the problem.

https://github.com/rhelmus/virtmem

Extract "virtmem is an Arduino library that allows your project to easily use an external memory source to extend the (limited) amount of available RAM. This library supports several memory resources, for instance, SPI ram (e.g. the 23LC1024 chip from Microchip), an SD card or even a computer connected via a serial connection."

SDRAM connected to the gfx connector is just like a SPI RAM. With virtmem this SDRAM extends memory of a Teensy for framebuffer.