Jump to content


  • Content Count

  • Joined

  • Last visited

About Endalvik

  • Rank
  1. Nevermind -- answered my own question (again): I did find where tabs get cleared before being rendered: gwin_tabset.c ==> gwinTabsetDraw_Std(), which eventually does indeed call gdisp_lld_fill_area(). So the root cause is that my accelerator slows down on unaligned accesses -- which of course will happen with pixels that are half-word! Back to the drawing (or rather filling) board...
  2. I am currently using uGFX with NIOS II (on MAX 10), using a generic framebuffer with 16-bits/pixel (RGB565). As part of the linear framebuffer driver, I have added accelerators for gdisp_lld_fill_area(), etc. I have confirmed that I am getting must faster fill than the default fallback "// Worst is pixel drawing" code. In my main application, I have a tabset (with 3 tabs) that fills the entire display. Anytime I select a new tab, I notice an unexpectedly slow tab window clear, right before the newly selected tab is rendered. Subsequently, I am seeing expected performance while drawing filled shapes, so I am confident that my accelerated gdisp_lld_fill_area() is still being called. I have started to look through gdisp.c, but have yet to identify exactly where this tab change window clear is being executed. Could someone point me in the right direction? I would like to make sure that tab window clear is using my accelerated functions. Thanks in advance.
  3. Update: working around this by creating and retrieving hard-coded calibration data, per the wiki. I am not needing general calibration, as the touch/LCD are physically matched (aside from the flipped/inverted Y). Now have this in my custom board_framebuffer.h: // Force in calibration data, to compensate for hardware configuration float calibrationData[] = { 1, // ax: no change 0, // bx: no change 0, // cx: no change 0, // ay -1, // by: flip Y axis SCREEN_HEIGHT-1 // cy: flip Y axis }; gBool LoadMouseCalibration(unsigned instance, void *data, gMemSize sz) { if( sz != sizeof( calibrationData ) || instance != 0 ) { return FALSE; } memcpy( data, (void *)&calibrationData, sz ); return gTrue; } However, this is not ideal as now every single touch/movement now has costly floating-point math overhead. I am open to suggestions on a lower-overhead (yet consistent) way of handling touch hardware that is flipped/inverted. Thanks.
  4. I have a LCD panel that implements capacitive touch using the FT5406. Oddly, the touch Y axis is inverted/flipped relative to the display Y axis. To compensate for this, I would like to add an axis invert/flip option. I cannot find any such option while inspecting the code for ginput / gmouse / FT5x06 driver, etc -- though perhaps I am simply missing it. Can you recommend how best to add this too the code? For instance, would it be appropriate to add "flipY" (and "flipX") flags to the GMouse struct, and then allow read_xyz() to perform the inversion arithmetic? Thanks!
  • Create New...