Announcement

Collapse
No announcement yet.

Best practice of restoring background image on WVGA?

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Best practice of restoring background image on WVGA?

    Hello all, I'm new to this forum and to the 4D product line. I'm using the uVGA-II GFX module to display a dashboard of a car. It should display the usual gauges (RPM, tach, fuel, coolant etc) and will have some LCD-like area. To make it look good, I'm loading a background image (with some fancy gaugwes on it) from the uSD and I would like to draw the needles on the fly, then restore (somehow) the area which was painted over. I have 4 needles (1 big and 3 shorter ).
    I'm using the image control functions (file_LoadImageControl() and img_Show()), because file_image() did not work, for some reason it did not paint the whole image, just the top one and half lines of it... strange. :/

    I was aiming for around 10 fps (at first, it was a reasonable goal as I thought video access is fast and I can use the remaining video memory sequentially).

    At 800x480, I don't have much space left from the video memory to use. The complete reloading of the image (from FAT) resulted around 2fps (with just one line drawn as a needle)... bad idea.

    I feel I don't have many options:
    1. Do away with the bitmap 'skin' concept and draw the gauges via API. It will be a lot uglier (The Cool Gauge looks cool, but it does not give enough freedom and I would have to display four of it which I think is beyond scope), but repaint is easier.
    2. Looking for a way to access either the video memory or the SD card, to restore The painted area quickly.
    4. Splitting up the gauge images to portions based on transparent background (scale, base of axle of needle, numbering etc.) and rebuilding the gauges by just clearing the messed up area and re-painting from the smaller pieces made transparent (unoccupied space remains background-colored, I assume, transparent pixels will not be processed, thus speeding up the paint process).
    3. Going down with the resolution (to 480x272, giving me at least 2 video pages) and using the invisible one as a clipboard or flipping pages. This would result in severe pixelation of a 7" TFT.

    My general questions about this my apparent options:
    * Do the unrelated system resources (like the uSD card usage) affect the performance of the graphic functions? I'm asking because I don't unmount the uSD drive after displaying the background image.
    * Can the remaining video memory (30k) be used? I did not try it but I assume the gfx_ScreenCopyPaste() does not work so that the copied area is placed to the invisible vid memory as sequence of the lines after each other (this way 30k would be more than enough to save the rectangular area as a sequence of lines).
    * As I read on related topics, the video memory access is not fast and (raw) uSD usage could be an alternative if done right. Is there a way to get just a rectangular portion of the image from the uSD card (the region covers the needle area)?
    * Is calling GetPixel() cyclically an alternative, in terms of speed? I was thinking about writing a line drawing function which stores each pixel color before PutPixel() into RAM and the original image could be restored later, at the sake of some RAM (e.g. 2k, accepable trade-off for me). A needle can be drawn from a couple of hundred pixels and the very same draw funtion could just read all the pixels in the sequence it was overwritten, when one restores in the very same sequence he drew. Would the calculation of the line points in 4dGL much slower than using the line drawing function (ignoring the getpixel() execution time) ?
    * I'm using the Orbit function to calculate the needle positions. I assume it uses the SIN and COS functions. Apart from giving only 1 degree precision (on 100px radius, needle positions have already gaps), would it be faster with some FLASH look-up tables and does it give me enough benefit (-> extra time) to worth the effort?
    * Does the 'raw' uSD access compete with the usage of the video memory (I'm thinking of resotring a rectangular image area)? I assume, not using a FAT chained list for read makes it faster..

    Any help or info would be greatly appreciated!

    Best Regards

    Balázs

  • #2


    Wow, what a mouthful Let's see if I can try and answerit all.



    file_Image should work, can you give a code snippet that demonstrates how you were trying to use it and the problem?



    800x400 should give about 2.4fps.



    The read routines from the uSD are highly optimised, so the best 'image' performance comes from reading an image off uSD.



    What is it that you don't think can be achieved with Cool Gauge? (err other than the speed, you will only be able to drive 2 200x200 gauges at ~10fps at once)



    As I said to someone else, why 10fps? An analogue meter probably doesn't do 10fps, it might appear to, but it will have lag and overshoot, it will only be accurate when it's not really moving.



    You could certain do away with the skin, but, as you say, it will be a lot uglier.



    To restore part of the screen, try this.

    gfx_ClipWindow(sx,sy,ex,ey) ;

    gfx_Set(CLIPPING, ON);
    img_Show(hndl, skin);


    I think trying to repaint 'messed up' bits will be slower than repainting the lot, as a lot of time will be spent calculating the 'messed up' bits. Of course, if you can come up with a fast algorithm.



    Dropping the resolution will make the whold thing faster, such that you may not even need to use the invisible page. Try it, the pixelation may not be as bad as you think.



    The uSD has no 'housekeeping' it's only used when it's used.



    You can use the remaining memory, I've never tried it, but there is a 'mouse' demo around that uses that technique.



    GetPixel is fairly slow, as it has to set the video position for each call. So copying video memory is faster (using the technique in the mouse demo, I think).



    Orbit uses a lookup table internally. So unless you are doing some calculations that could use a lookup table in 4DGL to save some calculations, it wont be faster to have your own table.



    The video memory and uSD memory are separate, the usage of one does not affect the other. RAW is faster than FAT, but depending upon what you are doing the difference is quite small.
    Mark

    Comment


    • #3


      Thanks for taking your time to answer my questions!
      I went into details to cut the possible dead ends in the project short.
      I will look for the source code that let me down on the first attempt...
      Since I go for wide screen, only the standard wide-screen resolutions apply (800x480 or 480x272), otherwise 1:1 pixel mapping is lost, making the image distorted and blurred (or leaves unused screen areas, also unwanted).
      I saw the mouse example (I read some older posts in this forum to see if there's a workaround for a problem similar to mine), but I think it's working by keeping the form factor of the copied image (if you have, say 10x10px to copy but your resolution results in only 5 remainig complete lines in video memory, only the first 5 lines will fit, all of the lines having only 10pixels of copied data beolw each other). But I will have a try then this method as well.
      10fps is a must to maintain smooth animation, as this dash is meant for custom cars, if it looks too 'ordinary' or moves chunky, it's not a keeper.
      An RPM counter is generally a dynamic instrument, the aim is to be able to keep track of it dynamically rather than the actual value. Here, the emphasis is on the 'show' and the smooth movement (peripherical vision makes sluggish animation even more evindent). I have yet to go for a working CoolGauge project (with no floating point error messages in Workshop, when I open the example, sometimes the toolbar disappears to... ). CoolGauge draws a complete round gauge but I just need partial dials, even overlapping each other (I'm sure you saw such gauges before). Some more fancy gauges I'm using don't have the needle of the gauge starting from the center (it's like the speedo of a Mercedes E-Klasse), it has a round-shaped LCD in the center.
      Thanks for the code snippet!
      Does the use of clipping improve performance for img_Show() (ignoring irrelevant pixels), am I getting you right?
      About the FAT vs RAW access: I'm looking for some extra performance when restoring the background skin. But not necessarily if the gain is negligible.
      As I said, a lower resolution heavily affects the quality and is the last resort (it also affects what kind of TFT I have to choose). I also have az LCD-like area to put warning symbols and text, this are would also suffer from a lower resolution (less information as it shall be readable).
      I try to get the most out of the platform as I will need runtime for processing the data messages (coming from serial port) to parse and decode the signals to display as well.
      Thanks for the info on the internal working on the Orbit functions, I will stick to it until this will be the biggest problem.

      Best Regards

      Balázs

      Comment


      • #4


        I have yet to go for a working CoolGauge project (with no floating point error messages in Workshop, when I open the example, sometimes the toolbar disappears to... ).



        Can you describe in detail as to how you get that to happen?



        CoolGauge draws a complete round gauge but I just need partial dials, even overlapping each other (I'm sure you saw such gauges before).


        You could certainly produce a partial dial with it, it's got lots of options that take quite a bit of getting used to. You'd have to use clipwindow to stop it from overlaying the next door gauge, or course
        Mark

        Comment


        • #5


          Can you describe in detail as to how you get that to happen?




          I installed Workshop and opened the coolgauge sample. See the attached screenshot. After that, the text in the editor and the toolbars disappear. The error is sporadic and sometimes I manage to see everything.




          I think this might be in conjunction with the decimal separator being different for different Windows language versions (I use Hungarian Windows). My suspicion is that this error is caused text to float conversions, where the decimal separator was hard-coded to be "." (dot) character (in the Hungarian international settings this is the thousand separator, demical is the "," or comma) instead of the getting the character from the operating system. Some Windows application suffer from this issue and it may affect more countries as well. But this is just my idea as I met this problem before in some application development projects.





          You could certainly produce a partial dial with it, it's got lots of options that take quite a bit of getting used to. You'd have to use clipwindow to stop it from overlaying the next door gauge, or course



          Thanks, I'll take a look when it comes to life.

          Attached files

          Comment


          • #6


            Great thanks, we'll get that fixed.
            Mark

            Comment


            • #7


              Have you seen this? http://www.youtube.com/watch?v=lnsf2-4iN_o[/video]]
              Atilla

              Comment


              • #8


                [quote]Have you seen this?

                Comment

                Working...
                X