Skip to content

Variable display size - #48

Open
amb5l wants to merge 1 commit into
tuupola:masterfrom
amb5l:variable-display-size
Open

amb5l wants to merge 1 commit into
tuupola:masterfrom
amb5l:variable-display-size

Conversation

@amb5l

@amb5l amb5l commented Aug 27, 2021

Copy link
Copy Markdown

Do not initialize clip_window if display width and height may be changed at runtime - rely on HAL to initialize instead.

Do not initialize clip_window if display width and height may be changed at runtime - rely on HAL to initialize instead.
@amb5l

amb5l commented Aug 27, 2021

Copy link
Copy Markdown
Author

Thank you for this excellent project which I am using to prove an embedded graphics controller in an FPGA. My hardware supports multiple display resolutions so the initialization of clip_window needs to change for my application.

@tuupola

tuupola commented Aug 27, 2021

Copy link
Copy Markdown
Owner

What can be gained by leaving the window_t clip_window empty? It forces an initial call to hagl_set_clip_window()which you probably want to do anyway after changing the resolution.

@amb5l

amb5l commented Aug 27, 2021

Copy link
Copy Markdown
Author

My framebuffer driver maintains the current display size as

uint16_t fb_width;
uint16_t fb_height;

So in my hagl_hal.h I have

#define DISPLAY_WIDTH fb_width
#define DISPLAY_HEIGHT fb_height

This results in an error when compiling hagl.c: initializer element is not constant

@tuupola

tuupola commented Aug 27, 2021

Copy link
Copy Markdown
Owner

Yes the C preprocessor does not allow you to do that. Are you changing resolution runtime or do you configure the resolution when compiling? If the latter then you can use those configuration values as DISPLAY_WIDTH and DISPLAY_HEIGHT.

If you change resolution runtime you will run into other problems since code currently relies on DISPLAY_WIDTH and DISPLAY_HEIGHT to be defined on other places. Changing resolution runtime has not really been taken into account.

This could to be another reason why changing the API to include the surface in the API calls (see #43). Then one could do something like:

#include <hagl_hal.h>
#include <hagl.h>

surface_t s = hagl_init();

hagl_load_image(s, 0, 0, "/sdcard/foo.jpg");
hagl_hal_change_resolution(s, 320, 240);
hagl_set_clip_window(s, 0, 40, s.width, s.height - 40);
hagl_load_image(s, 0, 0, "/sdcard/bar.jpg");

hagl_close(s);

One thing to consider though is how often you have an embedded project where you to change display resolution on runtime.

@amb5l

amb5l commented Aug 27, 2021

Copy link
Copy Markdown
Author

I am changing the resolution at runtime. My CPU is testing my frame buffer hardware in various resolutions. My simple tests are running OK with the change to clip_window initialization, so this is not a high priority. Let me get a more complete test working which I can show you, and which may suggest a better way forward, or perhaps that my application is an edge case not worth considering.

@tuupola

tuupola commented Aug 27, 2021

Copy link
Copy Markdown
Owner

Sounds good!

@amb5l

amb5l commented Sep 3, 2021

Copy link
Copy Markdown
Author

My FPGA hardware and test software is working well. The repo is here and documentation for the graphics design is here. I don't think you need to take account of my application - I've forked hagl and my project links to that fork. Thanks again for a great piece of work.

@oclyke oclyke mentioned this pull request Oct 9, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants