inmarket

Your original font problem likely stems from a bug in the GDISP driver for the EMBEST board with bitmap displaying. When in 90 degree mode it is likely that the bitmap routines are not rotating bitmap displays correctly. The new font code does not use bitmap routines and so the problem has "appeared" to go away with the new font code. It will still exhibit however if you try to display any bitmaps. Tectu, can you please test bitmaps on the EMBEST in the rotated configuration as I don't have this type of hardware?

This smells of being a stack issue. Try increasing the size of your runtime stack. Looking at the code fragment below however, it looks like you are rotating to 90, performing some operations and then rotating back to 0. If so, this may have all sorts of strange effects as the window has been created in one orientation but is being operated in a different orientation. This is definitely an untested (and probably unsupported). In general, gwin windows should be operated in the same orientation that they are created.

Sorry for the late reply to this thread. This area of uGFX is fast evolving and there are a number of competing requirements. On one hand uGFX gets run on some CPU's with very little RAM - so generally buffering display area's is a big no-no. On the other hand - we used to have progressive, non-frame effect text fills with the old fonts code. Whilst it didn't optimize out overdrawing of pixels (which is not possible without buffering or display read-back), it did update in a smooth manner - filling as it was drawing each changed character. For unchanged portions of the text there was no visible display change. This capability was dropped when converting to the mcufont library simply because of the complexity of the code required due to mcufont supporting kerning. I am currently doing major work in the basic GDISP library and drivers which will include significantly reduced stack usage, significant performance optimisations, support for multiple displays, support for area streaming (as might be used by video). I will look at re-implementing the progressive text filling as I go as it definitely a nice feature.

There is still a bug here in the driver scrolling routine. GDISP_CONSOLE_USE_CLEAR_LINES just clears to the end of the line. Whilst turning this off has made the problem "seem" to disappear it is actually still there. The issue will continue to appear any time you try to fill an area using gdispFillArea(). What is happening is that because your driver has not defined a "fillarea" routine (or it is not turned on in your driver config file) the emulation layer looks for an alternative mechanism to quickly fill the area. In this case it has determined that you have a vertical scroll routine so it is using that to fill the area. If you look at the documention for gdisp_lld_vertical_scroll() you will see that it is supposed to clear the new area revealed by the scroll operation. In this case the entire area is being scrolled out which should result in the entire area being "revealed" and therefore cleared. Have a look at your code in the gdisp_lld_vertical_scroll() routine specificly for this boundary case. It is probably a good idea for performance reasons to also create and turn on a fill area routine.

Perhaps Tectu or Mobyfab would like to put together a readme on common problems someone might see with this (or similar) drivers and the steps that can be looked at to address the problems. TechNet supplied images as part of his discussion which made it obvious to the experts mobyfab and Tectu what might be happening. Similar images in a readme would help other users to self-diagnose their new panel.

I have just updated the button code to fix the compile error there. It was being caused by extra custom button drawing routines that are not always compiled in. With regard to "gfxQueueASyncInit" - it is defined in include/gqueue/gqueue.h It is turned on by having #define GFX_USE_GQUEUE TRUE #define GQUEUE_NEED_ASYNC TRUE in your gfxconf.h This should have automatically been set anyway when the GWIN Window Manager is compiled (include/gfx_rules.h). If that is not working for you just add the above lines to your gfxconf.h and it should make sure that that function is defined.