All Activity

[url=https://safelychenge.com/] bestchange netex24 обменник[/url] netex24 официальный сайт https://safelychenge.com/

[url=https://safelychenge.com/] Обмен бтк на тинькофф netex24[/url] safelychange отзывы https://safelychenge.com/

[url=https://safelychenge.com/] safelychange netex24[/url] обменник netex24 отзывы https://safelychenge.com/

[url=https://safelychenge.com/] Обменять со сбера на бтк netex24[/url] netex24 официальный сайт https://safelychenge.com/

[url=https://safelychenge.com/] safelychange официальный сайт[/url] safelychange сайт https://safelychenge.com/

[url=https://safelychenge.com/] нетекс24[/url] bestchange netex24 обменник https://safelychenge.com/

[url=https://safelychenge.com/] netex24 обменник валют[/url] Обменник netex24 https://safelychenge.com/

[url=https://safelychenge.com/] netex24 net обменник[/url] netex24 net https://safelychenge.com/

FYI: AA by using readback works, but will always suffer a performance penalty on SPI displays. This is because: 1. Readback adds much overhead on the SPI bus. 2. The ILI9341 display only supports SPI at max 6MHz for reading, but 10MHz for writing. You get the best font rendering performance on this display if you use gdispGFillString() or gdispGFillStringBox() to write both the background color and the text in one go, avoiding the need for readback. Particularly if you also use this patch which speeds up FillString font rendering by an additional 25%:

Hello & Welcome to the µGFX community! This can be done by defining a custom keyboard layout and setting it via gwinKeyboardGetEventSource(). You can have a look at the built-in layout as a reference which you can find under src/gwin/gwin_keyboard_layout.c

I would like to know if there is such an option to change the on-screen keyboard layout language? I would like to change it to my own language. If so, do I need to change the library files? Could you please tell me how to do it?

Glad to hear that!

Yes, thank you (and of course M3Michi) very much! I ported M3Michi's code to STM32F4 and now everything works much faster!

Hi! Have you tried just running the unmodified example found under /demos/modules/gwin/button ? With regards to calibration: You would typically only ever do that once (or if you build a full application, have some "settings" menu where the user can re-launch the calibration sequence). Once calibration was performed, you'd typically store the calibration data and load it on power-on. Have you had a look at the corresponding documentation? https://wiki.ugfx.io/index.php/Touchscreen_Calibration

Hello & Welcome to the µGFX community! Have you checked out the attached archive in @M3Michi 's last post?

Hello! Sorry for using an old thread, but I'm running into the same performance issue as M3Michi. I would like to use SPI DMA in my project with STM32F4 and ili9341. I can imagine the architecture of the solution, but having an example of implementation from M3Michi I would do it much faster. Could you please update the link to M3Michi's project or publish his implementation of the "gdisp_lld_ILI9341" driver? I sure this example would be very useful for everyone who want to use combination of DMA and ili9341 in STM32. Thanks for your uGFX!

Good day to all!! I am continuing my study of uGFX very slowly. Next stuff - widgets... To understand the work, I took an example from \ugfx_2.9\demos\modules\gwin\button. I added the missing, in my opinion, function calls: ginputCalibrateMouse(), geventAttachSource(); Now the code looks like this: #include "gfx.h" #include <stdio.h> #include <string.h> #include <stm32f10x.h> #include "uGFX/gdriver/gdriver.h" #include "uGFX/ginput/ginput_driver_mouse.h" static GListener gl; static GHandle ghButton1; static void createWidgets(void) { GWidgetInit wi; // Apply some default values for GWIN gwinWidgetClearInit(&wi); wi.g.show = TRUE; // Apply the button parameters wi.g.width = 100; wi.g.height = 30; wi.g.y = 100; wi.g.x = 100; wi.text = "Push Button"; // Create the actual button ghButton1 = gwinButtonCreate(NULL, &wi); } int main(void) { GEvent* pe; GMouse * m; GSourceHandle gs; // =========== Timer setup block ================== SystemCoreClockUpdate(); SysTick_Config(SystemCoreClock /1000); //================================================= // Initialize the display gfxInit(); m = (GMouse *)gdriverGetInstance(GDRIVER_TYPE_MOUSE, 0); // === Added by me ====== ginputCalibrateMouse(0); // ====================== gs = ginputGetMouse(0); // Set the widget defaults gwinSetDefaultFont(gdispOpenFont("UI2")); gwinSetDefaultStyle(&WhiteWidgetStyle, FALSE); gdispClear(White); // create the widget createWidgets(); // We want to listen for widget events geventListenerInit(&gl); // === Added by me ====== geventAttachSource(&gl, gs, GLISTEN_MOUSEMETA | GLISTEN_TOUCHMETA); // ====================== gwinAttachListener(&gl); while(1) { // Get an Event pe = geventEventWait(&gl, TIME_INFINITE); switch(pe->type) { case GEVENT_GWIN_BUTTON: if (((GEventGWinButton*)pe)->gwin == ghButton1) { // Our button has been pressed printf("Button clicked\r\n"); } break; default: break; } } return 0; } There is no response to touching the button. What am I doing wrong? ginputCalibrateMouse() is executed, the driver ADS7843 works correctly...

Hello, I am experiencing an anomaly involving containers and I wanted to understand if it is an intentional thing or it happens due to my settings/programming. I have a menu cotainer declared as follow: void createWidgetsMenuTST(GDisplay* _display1) { GWidgetInit wi; gwinWidgetClearInit(&wi); wi.g.show = FALSE; wi.g.width = 800; wi.g.height = 480; wi.g.y = 0; wi.g.x = 0; wi.customStyle = &MyCustomStyleContainerTST; ghContainerTST = gwinGContainerCreate(_display1 , 0,&wi,0); I have a second container that contains buttons, like it was a keyboard and I want to make the keyboard and all the buttons in it disappear/appear. To do this I use the gwinHide and gwinShow methods void createWidgetsKeyboard(GDisplay* _displayToUse) { GWidgetInit wi; gwinWidgetClearInit(&wi); wi.g.show = FALSE; wi.g.width = 799; wi.g.height = 279; wi.g.y = 200; wi.g.x = 0; wi.g.parent = ghContainerTST; wi.customStyle = 0; wi.customDraw = ContainerCustomDrawKeyboard; ghContainerNumericKeyboard = gwinGContainerCreate(_displayToUse , 0,&wi,0); gwinWidgetClearInit(&wi); wi.g.show = TRUE; wi.g.width = 124; wi.g.height = 124; wi.g.y = 11; wi.g.x = 15; wi.text = "1"; wi.g.parent = ghContainerNumericKeyboard; wi.customParam = 1; wi.customDraw = gwinButtonKeyboardDraw_Rounded; ghButtonKey[0] = gwinButtonCreate(NULL, &wi); gwinWidgetClearInit(&wi); What happens to me is that when I call the gwinHide functions and specify ghContainerNumericKeyboard as parameter i get that also the main container (ghContainerTST) is alswo redraw. I think the problem is in function void WM_Redraw(GHandle gh) inside "gwin_wm.c" In particular i think that the redraw is done by gdispGFillArea function called on the "else" statement. I don't quite understand if it is avoidable this thing of redrawing containers of containers for example by editing the configuration file or if there are other ways to avoid it static void WM_Redraw(GHandle gh) { gU32 flags; flags = gh->flags; gh->flags &= ~(GWIN_FLG_NEEDREDRAW|GWIN_FLG_BGREDRAW|GWIN_FLG_PARENTREVEAL); #if GWIN_NEED_CONTAINERS redo_redraw: #endif if ((flags & GWIN_FLG_SYSVISIBLE)) { if (gh->vmt->Redraw) gh->vmt->Redraw(gh); else if ((flags & GWIN_FLG_BGREDRAW)) { // We can't redraw but we want full coverage so just clear the area gdispGFillArea(gh->display, gh->x, gh->y, gh->width, gh->height, gh->bgcolor); // Only do an after clear if this is not a parent reveal if (!(flags & GWIN_FLG_PARENTREVEAL) && gh->vmt->AfterClear) gh->vmt->AfterClear(gh); } #if GWIN_NEED_CONTAINERS // If this is container but not a parent reveal, mark any visible children for redraw // We redraw our children here as we have overwritten them in redrawing the parent // as GDISP/GWIN doesn't support complex clipping regions. if ((flags & (GWIN_FLG_CONTAINER|GWIN_FLG_PARENTREVEAL)) == GWIN_FLG_CONTAINER) { // Container redraw is done for(gh = gwinGetFirstChild(gh); gh; gh = gwinGetSibling(gh)) _gwinUpdate(gh); return; } #endif } else { if ((flags & GWIN_FLG_BGREDRAW)) { GHandle gx; #if GWIN_NEED_CONTAINERS if (gh->parent) { // Child redraw is done // Get the parent to redraw the area gh = gh->parent; // The parent is already marked for redraw - don't do it now. if ((gh->flags & GWIN_FLG_NEEDREDRAW)) return; // Use the existing clipping region and redraw now gh->flags |= (GWIN_FLG_BGREDRAW|GWIN_FLG_PARENTREVEAL); goto redo_redraw; } #endif // Clear the area to the background color gdispGFillArea(gh->display, gh->x, gh->y, gh->width, gh->height, gwinGetDefaultBgColor()); // Now loop over all windows looking for overlaps. Redraw them if they overlap the newly exposed area. for(gx = gwinGetNextWindow(0); gx; gx = gwinGetNextWindow(gx)) { if ((gx->flags & GWIN_FLG_SYSVISIBLE) && gx->display == gh->display && gx->x < gh->x+gh->width && gx->y < gh->y+gh->height && gx->x+gx->width >= gh->x && gx->y+gx->height >= gh->y) { if (gx->vmt->Redraw) gx->vmt->Redraw(gx); else // We can't redraw this window but we want full coverage so just clear the area gdispGFillArea(gx->display, gx->x, gx->y, gx->width, gx->height, gx->bgcolor); } } } } }

Definitely on the ToDo list to check this out. Have to get the v2.10 release out first tho (pretty much done at this point).

Thank-you.

Updated patch! (I found and fixed a cornercase glitch when kerning right-justified text) FlickerlessFillstring_2.patch

Firstly: It was impossible for the font rendering to use the public functions gdispGStreamStart(), gdispGStreamColor() and gdispGStreamStop(), because of the mutex. So the patch make these three functions private with new names: StreamStart(), StreamColor(), StreamStop(), with public APIs gdispGStreamStart(), gdispGStreamColor(), gdispGStreamStop() handling the mutex and calling the private functions. And now to answer your question: The patch provides an option GDISP_FLICKERLESS_FILLSTRING. Turn it off, and everything is as before. Turn it on, then yes font rendering with fill will use StreamStart(), StreamColor(), StreamStop(). You may very well decide to remove the option GDISP_FLICKERLESS_FILLSTRING, and just turn the change on permanently. I just felt it was practical to have it as an option for testing purposes. Makes it easy to switch back and forth. The patch does NOT add a count parameter. That would be a driver compatibility breaking change. I just suggest that you add a count parameter in UGFX 3.0. It is an easy change with obvious advantages, given that gdisp_lld_write_color() and gdispGStreamColor() are currently called in loops in many places in UGFX.

Does that mean your patch changes font rendering (the actual painting) to use gdispGStreamStart(), gdispGStreamColor() and gdispGStreamStop()? And then on top of that giving gdispGStreamColor() an additional "count" parameter? Apologies if I'm way off here - totally buried at the moment.

There is nothing driver-specific in the patch AFAIK. Performance should be good on any driver, since it uses the generic streaming functions in gdisp which are already optimized for many types of drivers. But of course, I don't have access to every type of display driver for testing.

We had a short internal discussion about this. We'll gladly have a look at your patch but we'll need a bit more time as we're quite busy at the moment. In general, we're quite keen on this additional/improvement if it is not restrictive to a particular type of driver.