Support for Digole displays

[Nikki]

Hi,

I'd like to try uGFX with Digole display. It does not have frame buffer interface. It is connected over serial bus (uart, spi or i2c) and controlled by high level graphic commands like: draw_pixel, draw_line, draw_circle, draw_rect, draw_bitmap, move_rect_area, set_clip_region. It also have some flash onboard, and command sequences can be stored in it and replayed as macros. Also it has loadable fonts and can render text by itself. Here is the command reference: http://www.digole.com//images/file/Tech_Data/Digole_Serial_Display_Adapter-Manual.pdf

The serial bus limits the speed of rendering, so the window driver mode it possible but impractical. I'd like try "point and block" model. However I cannot understand quite well how can I make use of accelerated Digole's commands draw_circle, draw_bitmap, move_rect. Or is it possible at all.

[chodzikman]

Hi,

I think you can search where gdisp_lld_fill_area() is called when you draw rectangle primitive, implement draw_circle as gdisp_lld_draw_circle() and add call to this funtion in circle primitive routine same way as it is called in rectangle and proceed with each accelerated functions.

[inmarket]

Adding your own accelerated functions is generally not a good idea for several reasons:

• It disrupts the driver model and makes it incompatible with every other driver and with multiple display scenarios.
• It makes it incompatible with work currently progressing on uGFX V3
• It creates a custom modified version of uGFX that cannot be updated easily as we change uGFX or fix bugs
• Unless those modifications are submitted back to the repository it will breach the license agreement (any custom modifications to uGFX itself need to be contributed back under the license agreement)
• On most small controllers, the accelerated functions actually perform slower than the mechanisms we use to accelerate drawing despite the SPI interface. The reason is that the controllers simply do not run fast enough silicon.

 

[Joel Bodenmann]

I feel like we should add those interfaces ourselves anyway. They can easily be added, it's simple to maintain and using #ifdef macros means that it adds zero overhead to drivers that don't use it. I need hardware acceleration of primitives myself or another upcoming project anyway.
However, everything that @inmarket mentioned still applies though.

 

15 minutes ago, inmarket said:

Unless those modifications are submitted back to the repository it will breach the license agreement (any custom modifications to uGFX itself need to be contributed back under the license agreement)

Note that this doesn't apply to owners of a commercial license.

[chodzikman]

I have to point out that at this moment it is hard to implement uGFX driver for displays that works in approach of command list (this is similar situation as with FT80x), since they have clear limitations with standard pixel drawing method. It can create huge value for some customers if uGFX could create list of primitives to share with graphic coprocessor, since it can allow better styling capabilities than enginge built in hardware driver. As far as I know uGFX would be the only library to provide such behavior at the moment.

What I meant was contribution to the library with expansions (hopefully) consistent to current design patterns by simply adding new Optional Routines.

 

EDIT: there will be still some problems with handling texts

Edited April 24, 2017 by chodzikman

[inmarket]

V3 is where some of these acceleration issues are being dealt with. If you have a suggested controller I will work on ensuring the new architecture can be extended for it.

[chodzikman]

I recommend you this one (I guess you will have local distributor of this company around):

https://riverdi.com/product/rvt4-3b480272cfwc81/

Or just plain FT800/FT801/FT811 chip to connect standard 4,3" RGB module

It seems to be quite popular, and I have been using this chip for one of the projects, so I can advice on any problems

[Nikki]

14 hours ago, inmarket said:

 

• It makes it incompatible with work currently progressing on uGFX V3
• It creates a custom modified version of uGFX that cannot be updated easily as we change uGFX or fix bugs
• Unless those modifications are submitted back to the repository it will breach the license agreement (any custom modifications to uGFX itself need to be contributed back under the license agreement)

I have no problem with sending back my patched to uGFX. I'm rather worrying of the fact the V2 is at the end of its life, so there is no reason to improve it at the moment.

It would be great if accelerated circle and text drawing and font loading functions will be supported in V3's driver model.

[inmarket]

Those things will be looked at in V3

[Joel Bodenmann]

6 hours ago, Nikki said:

I have no problem with sending back my patched to uGFX. I'm rather worrying of the fact the V2 is at the end of its life, so there is no reason to improve it at the moment.

Things will be ported over to v3. v3 is not just a rewrite from scratch where we will drop everything that we made so far and completely drop v2. The "only" real difference between v3 and v2 will be the underlying (GDISP). driver interface. All the high-level stuff will stay mostly unchanged except for some simple renaming of types and API functions to keep it clean, consistent and to get rid of some namespace collisions. However, there is the GFX_V2_COMPAT macro (which is turned on by default) that maps all these back to the "old" v2 calls in order to stay completely backwards compatible except for the drivers - which we will all port to v3 if they are part of the repository and provide a guide for everybody else to do it with their own ones.

Long story short: Nothing you do now for v2 will be for nothing. If you're working on high-level stuff (everything above the drivers layer) you won't be affected at all and if you made changes to a driver or if you created a new driver you can either contribute it to the v2 repository and we'll port it for you or you can port it yourself to v3 once that stuff is ready.