Draw thru multiple screens

[ekondratiev]

Hello!

Could you help me? I try to make some kind of splitted screen. Just to draw images or lines on some one framebuffer image and than display it on two displays.

Is it possible with uGfx?

[Joel Bodenmann]

Hello ekondratiev and welcome to the community!

uGFX itself allows to connect two (or more) displays to the same controller. The displays can be the same or different types. You can then control each display independently from each other. If you want to display the same information on both screens you would either simply draw the same thing to both displays or you would, provided that you have enough memory, create a pixmap framebuffer of the size of the screens in memory and perform each drawing option inside of the frame buffer. Then you can simply dump the entire framebuffer to both displays and you'll have an exact copy on both screens without any additional drawing overhead.

Note that pixmaps are a feature of uGFX that we haven't properly documented yet. Essentially a pixmap is a virtual display of a given size in memory. You can draw to the pixmap like you would to any other display and then simply dump the pixmap to the actual display. You can have a look at the pixmap demo which you can find under /demos/modules/gdisp/pixmap.

You can find some more information about multiple displays here: http://wiki.ugfx.org/index.php?title=Multiple_displays

Please let us know should you have any additional questions.

~ Tectu

[ekondratiev]

Thank you for quick reply!

I need to display one big image (in fact, the set of different images in one big field) on multiple displays. So, this big image must be splitted by parts to be displayed.

As far as I understand, I could use pixmap and than split it inside the display driver module and than send to different displays. But in this case I need to check the changes and find out which displays are needed to be updated because the connection to these displays is rather slow.

Am I right?

Thank you in advance,

--

Eugene

[Joel Bodenmann]

I'm sorry but I have to clear things up a bit first: Do you need to display one big image across smaller screens or will each screen display a different image? Is each display an exact mirror copy of the other displays or will each display need to be able to display different things?

Also, can you tell us about your hardware resources? What system are you using? Do you have sufficient RAM to create a frame buffer for each individual display?

~ Tectu

[inmarket]

If you are wanting to display different parts of the image on different displays, this is easy to do in ugfx and you won't need to use pixmaps.

The api calls for drawing an image allow you to specify which part of the image you want to show on each individual display.

For speed reasons however you might consider using the image caching api or pixmaps unless your image is coming out of flash (using GFILE and ROMFS).

Both caching mechanism however use a lot of ram. You will need to experiment as to which is best in your circumstance.

[inmarket]

By the way, for smallish displays (320x240) that you tend to see on embedded systems, the speed of the display itself is seldom an issue. A well written program, a well implemented board file (the software interface that describes the cpu - display electrical interface) make the biggest difference to display speed.

The exception is some of the monochrome displays. These tend to be very slow

[ekondratiev]

Hello!

I need to draw one big image (a set of smaller pictures) across several displays. So, one picture could be cut by these displays. It's like Windows windows on two monitors. You can move, for instance, Chrome window as left part of it is displayed in one monitor, and right part on another.

I plan to run it under Linux on Raspberry Pi (or something similar) without X Windows and I have monitors, connected by Ethernet with some high level slow interface. RAM should be enough, so I think that pixmap buffer could work well.

Edited June 18, 2015 by Guest

[Joel Bodenmann]

May I ask you why you would not want to directly run a proper X setup on your Pi? Anyway: People have already successfully run uGFX on the Pi. We provide a linux framebuffer driver so you don't need any X. That part should definitely work and set-up quite quickly for you

As you have the required memory here is what I would do: I'd create one large pixmap frame buffer that is the size of all your displays. Then when rendering you can write the frame buffer to each display using the gdispGBlitArea() function. The parameters of said function allow you to easily draw just that part of the frame buffer that should go on each individual display.

To simplify things you could create your own rendering routine called something like renderPixmap() and it would automatically to through all your displays and split up the frame buffer correctly.

~ Tectu

[ekondratiev]

I try to prototype the device with external e-ink displays which will be connected thru Ethernet or so. And these displays will show some "windows" with information.

Okey, I'll try to implement such a big pixmap and some "renderPixmap" function to update all the screens.

Edited June 18, 2015 by Guest

[Joel Bodenmann]

Let us know should you face any problems. Good luck!

~ Tectu

[ekondratiev]

Thank you!

Let us know should you face any problems. Good luck!

~ Tectu

[Joel Bodenmann]

Sorry for the off-topic but can you from now on please use the "Post Reply" button at the bottom of each thread page to reply? Using the "Quote" button will add the previous message to your post and in well structured threads like this one it becomes messy. I removed the quotes from your previous posts.

Thank you for your understanding.

~ Tectu

[ekondratiev]

Ok, I just hadn't found it :-)

[Joel Bodenmann]

Perfect! Thank you Sir

~ Tectu

[ekondratiev]

Oh, I have a question.

Is it possible to make a pixmap 4-bits per pixel? To store 2 pixels in one byte.

Or 8bpp is minimum?

[Joel Bodenmann]

The pixmap is created using the exact same color format as your display controller. Otherwise you would have to translate each pixel and the main idea behind a frame buffer is that it uses the same parameters as the actual display so you can quickly transfer the frame buffer information to the display using burst writes.

~ Tectu

[inmarket]

In ugfx there are two pixel formats involved; the system pixel format and the display pixel format. For a single display they are always the same.

For multiple displays each display may have a different pixel format. The user selects (as part of their gfxconf.h file) the system format. It is normally picked to match the larger of the two device formats as translating colors is computationally expensive.

Pixmaps always work using the system pixel format.

4bpp is definitely possible eg 16 color grayscale, but is not supported by the framebuffer driver. Translating to and from 4bpp to other standard formats is very computationally expensive so if you want to do that you should write a custom framebuffer that supports that format and use that format throughout to avoid color conversions.