king2 Posted January 30, 2016 Report Share Posted January 30, 2016 Going deeper into uGFX.How you would implement label with transparent background (i.e. without fill_area)?We need to determine will we call fill_area or not in draw routine (or call one of functions above, or mix both functions into one with new 'fill' parameter).But how we can know that user wants label to be transparent?We cannot use special color for transparent color, because we have no unused color values. So we should add new parameter to label?Can customparam be used for this or this is not a good idea?Also I see two functions - gdispGFillStringBox() and gdispGDrawStringBox(), which differs only by couple of lines (assigning colors and calling fillarea() - fill label area or not).Why was choosed this method of drawing string line by two functions? Why not use one function with parameter, to fill label area or not?Thanks! Link to comment Share on other sites More sharing options...
Joel Bodenmann Posted January 30, 2016 Report Share Posted January 30, 2016 How you would implement label with transparent background (i.e. without fill_area)?We need to determine will we call fill_area or not in draw routine (or call one of functions above, or mix both functions into one with new 'fill' parameter).If the currently existing label widget does everything for you and you only want to make it look different then the right way to implement a label with a transparent background is to write a custom drawing routine which is explained in this article (please do not hesitate to ask if something in that article is unclear). Inside that drawing routine you'd use gdispGDrawStringBox() instead of gdispGFillStringBox().Note that you can dynamically change the used rendering routine during runtime by using gwinSetCustomDraw(). You can pass built-in rendering functions to that function too.Otherwise, depending on your needs, you can write a custom rendering function that conditionally clears the background or not. You can use the custom parameter for this. The nice thing about a void* is that you can either just pass a boolean or an entire configuration struct should you have more complex needs and still want to avoid writing a custom widget.But how we can know that user wants label to be transparent?If by user you mean the person that uses the uGFX library (the developer of the firmware) then he has to know whether he wants to use a transparent label or not. It depends on the application. As mentioned in another thread using transparent labels doesn't make a lot of sense because when the label text changes you are forced to clear the area somehow. If it's not done inside of the label rendering routine you'll have to do it externally by refreshing whatever is below the label which kinda breaks the purpose of having a window manager in the first place.In my opinion having the need for a label with transparent background is a strong indication that you'd want to write a custom widget instead. It again depends on your needs. If you for example want a label with a transparent background because you want to make a button with an image then use the existing image rendering routine of the existing button widget instead. It will draw the image and then the text on top of it so it behaves like it's a label with transparent background. If you have more specific needs write your own widget where you render the text on top of whatever it is by using one of the GDISP text drawing functions that doesn't fill the background.One of the limitations of the GWIN module is that each widget must be able to clear it's own background. This is a limitation we decided to have in order to keep the resource requirements as low as possible. So far the only exception we made is with the container where we supply a transparent rendering function because containers can be used to just logically group other widgets.We cannot use special color for transparent color, because we have no unused color values. So we should add new parameter to label?Can customparam be used for this or this is not a good idea?I'm afraid I am not sure whether I understand what you mean. If you want to be able to conditionally clear or not clear the background of a label then using a custom rendering function and using the custom parameter for this as explained above is the right way to go.If you have more complex needs you could add your own color format that supports transparency (eg. ARGB). That however will be more work than just writing your own widget (again, depends on what you want to archive).Also I see two functions - gdispGFillStringBox() and gdispGDrawStringBox(), which differs only by couple of lines (assigning colors and calling fillarea() - fill label area or not). Why was choosed this method of drawing string line by two functions? Why not use one function with parameter, to fill label area or not?Two main reasons for that:1) We feel that the two functions behave very differently and distinguishing them is easier by just looking at the function name rather than searching for some parameter hidden in the already very long list of parameters. Also, that parameter would either be a boolean value which would make it very hard to guess what the function really does for somebody who's reading the code or it could be a flag which would be harder to remember.2) We found that some compilers are having serious issues with passing function pointers conditionally which would be requires when using one function and just enabling/disabling the background filling by a function parameter.It's possible that there are other reasons why we settled this way. The code was written a long time ago and with increasing complexity of the uGFX library we can't remember every decision anymore. inmarket might have a follow-up on this one. After all it can just be a personal and very subjective preference as to point 1) and that it's possible to optimize this.I hope that helps ~ Tectu Link to comment Share on other sites More sharing options...
king2 Posted January 30, 2016 Author Report Share Posted January 30, 2016 Thank you for answer!You have mentioned that "We will eventually add a transparent background rendering option of the label widget ourselves (I put it on the ToDo list) but this won't happen before the weekend for sure." in other thread. I know how to achieve this right now (and wrote this already), but question was about how to do it right way (assuming 'label allowing transparency' is a part of stock uGFX). I mean that in future user (developer) can use label as now (with background) or can use it without filling label's area. So, label should have special parameter to turn on transparency (turn off filling). Draw routine should call function with fill or not, or just use this parameter to call one function with additional parameter (instead of both existing functions). So will be function like SetBackgroundFill(ghLabel1, FALSE), or wi.donotfillarea = 1, or something like this?I understand that transparent label requires clearing its area before it can be redrawed safely - in some cases (when changing text), or not (when changing just color of text, for example). So I try to guess right way how to do it, to be consistent with built-in transparency later.What about my own color formats and rewriting code, I always try not to make changes that can be avoided and i hate doubling of code like in two functions mentioned in previous message (may I got this some time ago while working with CPUs that had little RAM and ROM space), so it strange for me to trade firmware space for readability of code. This is why I asked about reasons to write two functions (with code overhead) instead of one. Link to comment Share on other sites More sharing options...
inmarket Posted January 30, 2016 Report Share Posted January 30, 2016 The reason is simple, most small micros have more rom space than ram space. Ram is a more presious resource. Link to comment Share on other sites More sharing options...
king2 Posted January 30, 2016 Author Report Share Posted January 30, 2016 Thanks! Link to comment Share on other sites More sharing options...
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now