emeb

OK. Looks like the best solution is to get pixmaps working, which means figuring out how to get the Xilinx Eclipse-based XSDK to build uGFX in the "classical way". Thanks.

My application updates several text fields on an ILI9341 display which is interfaced via a SPI port. When using the gdispGFillString() routine to overwrite a new text string on the display there is a noticeable tearing / flicker visible on the display. Looking at the underlying code for the gdispFillString() function it appears that the screen region is first cleared to the background color, then the text is rendered in the foreground color, so the time interval between the clear and render is what's causing the visible flicker. Is there an alternative way for me to update text on the display that would operate in a single pass? In other graphics libraries I've used off-screen buffers for this, but for uGFX that would mean pixmaps which as I understand it are not available for me because I'm using single-file include.

I've got an existing menu system that's based on a rotary encoder with pushbutton where the rotary action scrolls through menu items and the button selects them for entering submenus or editing parameters. Since it's all custom coded and requires a lot of duplicated effort (separate handlers for every menu page) I'd like to consider a more modern approach with event queues, widgets, etc. and I've been looking at using GWIN + GINPUT. Searching through the support forum it seems that the recommended path is to have the encoder + button generate GINPUT toggle events for clockwise, counterclockwise and press actions. I've studied some of the low-level details of the toggle handling system and I have concerns about responsiveness - in particular the polling interval is set to 200ms and only allows one event per "bit" per polling period. This seems to me like it would result in lost events if the user spins the encoder quickly. I suppose it would be possible to reduce the polling interval or build some queuing into my low level driver, but it's starting to seem rather kludgy. Is there an alternative approach that might be better suited for the fast responsiveness I need? I saw another user discussing generating keyboard events - would that be quicker?

Yes - that's the git repo I used. I misunderstood the 2 vs 3 wiki page to imply that v3 was already in git. At any rate, I'm better prepared for v3.

Just a quick follow-on: I built another project using single-file inclusion only this time I started with v3 from the git repo instead of the v2.8 tarball. It worked just fine and the OS & SPI shims I did for the 2.8 project required no edits. My understanding is that starting w/ v3 means I won't have trouble with pixmaps. Happy so far.

OK - no sense swimming upstream. I followed the single-file inclusion method described in the Using Eclipse page and it worked right out of the box so I'll move ahead with that. I recall reading in the Getting Started page that pixmaps don't work with single-file inclusion so I may have to find a workaround for that at some point. Thanks for the advice.

Thanks Joel. I'll give it a try. I notice that XSDK has an option for building a static library as a separate project that can then be referenced by other projects. Would there be any advantage to do that vs simply pulling all of uGFX into the main project?

I've got a personal project running on a Zynq, development under the Xilinx XSDK. I've got an ILI9341 display running with my own bare-bones graphics so I know the hardware aspect is sound. I'd like to add some nicer graphics and I'm looking over uGFX as an option. Since XSDK is based on Eclipse I should be able to add uGFX as described in the Eclipse section - is this the best way to do so? Has anyone else had any experience with this? (There's a strong chance that this project may lead to a commercial product, so if I can get it to work I'll be recommending my client purchase a license.)