Conversation
Do not initialize clip_window if display width and height may be changed at runtime - rely on HAL to initialize instead.
|
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 |
|
What can be gained by leaving the |
|
My framebuffer driver maintains the current display size as So in my This results in an error when compiling |
|
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 If you change resolution runtime you will run into other problems since code currently relies on 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. |
|
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 |
|
Sounds good! |
Do not initialize clip_window if display width and height may be changed at runtime - rely on HAL to initialize instead.