Jump to content

Joel Bodenmann

Administrators
  • Posts

    2,656
  • Joined

  • Last visited

  • Days Won

    2

Posts posted by Joel Bodenmann

  1. I am working on reproducing this. Unfortunately, I was unsuccessful so far.

    Here's my simple test case following your pseudo code:

    #include "gfx.h"
    
    int main(int argc, char* argv[])
    {
    	(void)argc;
    	(void)argv;
    
    	gfxInit();
    
    	// Open image
    	gImage myImage;
    	gdispImageOpenFile(&myImage, "640x480.bmp");
    	
    	// Create pixmap
    	GDisplay* pm = gdispPixmapCreate(640, 480);
    	gdispGImageDraw(pm, &myImage, 0, 0, 640, 480, 0, 0);
    	
    	// #1: blit the entire pixmap on the display - works correctly
    	gdispGBlitArea(GDISP, 0, 0, 640, 480, 0, 0, 640, gdispPixmapGetBits(pm));
    	
    	// #2: Blit a partial pixmap on the display with source coord (0,0) - works correctly
    	gdispGBlitArea(GDISP, 0, 0, 200, 200, 0, 0, 640, gdispPixmapGetBits(pm));
    	
    	// #3: blit a region from the middle of the pixmap to the display (source coord != (0,0))  - PROBLEM!!
    	gdispGBlitArea(GDISP, 200, 200, 200, 200, 200, 200, 200, gdispPixmapGetBits(pm));
    	
    	// Close the image
    	gdispImageClose(&myImage);
    
    	// Keep the application alive
    	while (gTrue)
    		gfxSleepMilliseconds(100);
    
    	return 0;
    }

    When running this, the window (display) shows the image as expected without any defects.

    Am I missing something obvious here?
    For reference, here is a ready-to-run Win32 project with the code shown above and the corresponding asset(s): win32_blit_test.zip

  2. We're currently in the process of migrating our git server.
    Up until now, we were running Gogs but we're changing over to Gitea.

    Any user accounts with last activities older than 6 months will not be migrated to the new server.
    If you'd like to get an account on the new git server (once migration is completed) please get in touch with us.

  3. I haven't had time to check out your code  yet - just the video. Looking good!

     

    5 hours ago, uriy said:

    My aim was to show for other persons that it's possible to do. Because thay told before it's impossible.

    What was their reasoning that it wouldn't be possible?

    if you like we might be able to improve this together and eventually put it into the official µGFX library so it's supported out-of-the-box :) 

  4. Hi!

    As you stated the existing text edit widget only allows for one line of text.
    The proper way of doing this is creating a new widget called MultilineTextedit and implement the functionality. It might make sense to use the exsting Textedit widget as a base for this (i.e. copy-paste & modify).


    Other than the API documentation you can find documentation on creating your own widget here: https://wiki.ugfx.io/index.php/Creating_a_widget

    Alternatively we can implement the widget for via paid support.

  5. Hello & welcome to the µGFX community!

    Yes that is still true. If you purchased an µGFX 2.x unlimited commercial license you can still use any 2.x release without any additional costs. This also applies if it's a new/different project or product as long as the license holder noted on the licensing document is executing the development/sale.

  6. What GINPUT driver are you using?
    This might very well be a driver "problem" (or feature).

    Can you reproduce the problem when you take you application code and compile it into a native Windows, Linux or MacOS application?

  7. Hello & welcome to the µGFX community!

    There are various ways of achieving this. For example, you can have a look at the /demos/applications/notepad demo which is a small paint-like application. To draw without handling the touch (mouse) inputs through widgets. Instead, it uses ginputGetMouseStatus() to retrieve the current mouse status.

    You can use the GTIMER module to implement the screen timeout easily.

  8. In that case I'd recommend to adjust whatever GDISP driver you have to handle that adjustment for you.
    How to do this depends on the GDISP driver model used but the overall idea remains the same: shift each pixel before the display controller gets access to it.

  9. Hi,

    Check the return code of gdispImageOpenFile(). It will tell you whether the image was loaded properly.
    The widget will not display the image if it wasn't loaded properly.

    In general I'd recommend you making sure that you can display the image using the imagebox widget before attempting to insert it into the list widget as this makes it easier to ensure that there are no underlying problems with the filesystem, image decoders and similar.

  10. Can you elaborate a bit on what you want to achieve? It this offset desired to be global to everything the display displays or just for certain widgets? Also, is this a permanent measure or should this offset change during runtime?

    If this is just a measure to align the UI of a machine with a display behind a panel I would recommend modifying the GDISP driver directly. This way your application remains unchanged and upgrading to future versions of µGFX will not require any changes.

  11. On 22/01/2021 at 00:07, br64 said:

    Where might I find info on how to set everything up on a Win10 environment?

    There's a getting started guide available here: https://wiki.ugfx.io/index.php/Your_First_Compile_-_Windows
    Keep in mind that µGFX is a library. It expects you to have a working development environment to which the µGFX library can just be added.

    @br64you can furthermore get free support on this community board or obtain a commercial support package.

    I'll close this question for off-topic.

  12. The current µGFX release (v2.9) introduces new types to make the interface more consistent and future proof. However, there's a define named GFX_COMPAT_V2 which makes the "old" types still available. This macro is by default on/enabled (in the main configuration file). Therefore, using the existing micropython port with the latest µGFX release should be a comparably easy task.

    Other than that: We're happy to help where we can. This forum is always at your disposal :)
    We'd certainly like to see an updated/active/maintained micropython port for the µGFX library.

    Late answer to your initial post: The badge is STM32L4 based.

×
×
  • Create New...