BRT Community

Please login or register.

Login with username, password and session length
Advanced search  

News:

Welcome to the Bridgetek Community!

Please read our Welcome Note

Technical Support enquires
please contact the team
@ Bridgetek Support

Please refer to our website for detailed information on all our products - Bridgetek - Bridging Technology

Author Topic: Filled Irregular Polygons - Mission Impractical  (Read 10555 times)

AT38

  • Newbie
  • *
  • Posts: 18
    • View Profile
Filled Irregular Polygons - Mission Impractical
« on: July 01, 2019, 01:13:36 PM »

Hi,

I was hoping to be able to draw filled polygons using an FT813 so that I can replace some large icon bitmaps with a small list of vertices, saving me a whole load of flash memory space.

I looked at application note AN334 https://brtchip.com/wp-content/uploads/Support/Documentation/Application_Notes/ICs/EVE/AN_334-FT801_Polygon_Application.pdf and I saw filled polygons.
On closer inspection, it seems that the polygon is split up into smaller sections so that they have vertical and horizontal edges for the scissor command to trim to.
This makes diagonals impractical however, as they would have to be cut up into squares whose sides match the width of the diagonal section. A long thin diagonal would require many cuts.
Concave polygons also need to be chopped up into straight edged convex pieces, and would need some thinking about..


Firstly, is filled concave polygons something that is likely to be supported in the future? Are the existing range of chips field upgradable, or would this feature require rolling out a new product?


Secondly, what would be the best way of getting around this?

1) I could draw over the unwanted part of the polygon with another polygon set to the background colour, but this wouldn't preserve non uniform backgrounds.

2) Perhaps I could draw to the stencil channel instead, but the stencil is 1bit and wouldn't have nice smooth edges when I fill, so far as I can tell from the docs, haven't tried it yet. I suppose I could then draw the outline with with a LINE_STIP to get the anti-aliased edges.

3) Or I could break up the icons into smaller components and composite them, making use of completely blank rectangular bitmaps that can be generated with the MEMFILL command and using the bitmap transform to rotate them to get the diagonals. Rotating bitmaps is a bit iffy, though. I did try animating a rotating circle and it did not look good. Its size and position kept shifting about.

4) Or I could give up and just use bitmaps, take the hit on space, hope deflate does a good job.

I think option (1) would suit my immediate needs, but I'd like to know if other folk have encountered this limitation, how they've gotten around it, and why that method, so I can make an informed decision before making a commitment.

Cheers,
 AT38
Logged

AT38

  • Newbie
  • *
  • Posts: 18
    • View Profile
Re: Filled Irregular Polygons - Mission Impractical
« Reply #1 on: July 17, 2019, 11:28:10 AM »

I noticed that edge strips don't anti-alias, so need to be outlined anyway.

Using Scissors is the easiest way for simple shapes, but doesn't allow for moving the shape using vertex offsets. For that, stencilling is required.

For shapes with relatively thin diagonals, drawing multiple parallel lines seems to be the easiest way.

I haven't been able to get compressed images to work yet. PNGs load, but return zero length.
I'm now trying to upload compressed raw L4 converted output from the Asset Converter. For some reason it doesn't compress files when 'compressed' is selected. I've written a python script to compress the raw files and output to c array, but so far I've only gotten errors from CMD_INFLATE.
Logged

BRT Community

  • Administrator
  • Hero Member
  • *****
  • Posts: 732
    • View Profile
Re: Filled Irregular Polygons - Mission Impractical
« Reply #2 on: July 17, 2019, 02:28:28 PM »

Hello,

You can have a look at section 7 of the following application note which covers loading PNGs and inflating images:
https://brtchip.com/wp-content/uploads/Support/Documentation/Application_Notes/ICs/EVE/BRT_AN_014_FT81X_Simple_PIC_Library_Examples.pdf

Best Regards,
FTDI Community
Logged

AT38

  • Newbie
  • *
  • Posts: 18
    • View Profile
Re: Filled Irregular Polygons - Mission Impractical. Also, compressed data.
« Reply #3 on: November 25, 2019, 11:48:33 AM »

Solved both problems:

1) It's possible to write to the display's alpha channel and use that as a mask.

Code: [Select]
DL_BLEND_FUNC(BLEND_ONE, BLEND_ZERO);
DL_COLOR_MASK(0,0,0,1);
DL_COLOR_A(255);
//draw mask areas
DL_COLOR_A(0);
//clear mask areas

DL_BLEND_FUNC(BLEND_DST_ALPHA, BLEND_ONE_MINUS_DST_ALPHA);
DL_COLOR_MASK(1,1,1,0);
//draw colour over mask

2) Compressed data is sent in two packets - one for the command, one for the data. No interruptions, no checking for command buffer space, no breaking up into 4092 byte chunks to fit the buffer. Send the whole compressed data in one go. It is consumed from the buffer as fast as you can send it.
Logged

AT38

  • Newbie
  • *
  • Posts: 18
    • View Profile
Re: Filled Irregular Polygons - Mission Impractical
« Reply #4 on: November 27, 2019, 05:24:43 PM »

Quote
It is consumed from the buffer as fast as you can send it.

No. No it isn't.
I have to run the SPI at 1.3Mhz, or put a 20ms pause between each batch of 4092 bytes to avoid swamping it.
No error is returned, just an incorrect size when calling CMD_GETPTR.
I don't know how much this is affected by compression ratio yet. This is with a custom font with a 12:1 compression ratio, and 144kB when inflated.
Still seems faster than using Miniz/tinfl.c by nearly 2x
Logged

Rudolph

  • Sr. Member
  • ****
  • Posts: 389
    • View Profile
Re: Filled Irregular Polygons - Mission Impractical. Also, compressed data.
« Reply #5 on: December 11, 2019, 03:07:47 PM »


Quote
>2) Compressed data is sent in two packets - one for the command, one for the data.
>No interruptions, no checking for command buffer space, no breaking up into 4092 byte chunks to fit the buffer.
>Send the whole compressed data in one go. It is consumed from the buffer as fast as you can send it.

This makes no sense at all since nothing is processed untill you set the end-address.
So writing more than 4096 bytes in one go will make the FIFO loop around and overwrite itself.
Unless you are using REG_CMDB_WRITE to write to the FIFO but this still requires precautions.

What you can get away with is setting the end-address, wait a little, write the next chunk of data, set the end-address, write the next chunk of data...
How long you need to wait before you can write again depends on what type of data you are writing, how fast your SPI is clocked and of course on the clock of the EVE chip you are using.
And of course there is REG_CMD_READ and REG_CMDB_SPACE.

I tested .jpg versus .png on the FT813 a while ago.
I used a very simple 100x100 icon that I made with paint and compared the processing time for a .png version with 3867 bytes to a .jpg version with 3903 bytes.
The .jpg version needed 480µs to process after setting the end-adress, the .png version needed 53ms to process.
So that was 110 times slower processing of .png over .jpg.

While only using REG_CMDB_WRITE with a .jpg at full SPI speed might work with buffers larger than 4k, it will fail with .png unless REG_CMDB_SPACE is read for every step.
Logged