1. Implement partial refresh.
2. Implement refresh canceling mechanism.
3. Refactor some parts of the gui and display code.
ad 1.
- Detect parts of the screen changed since last update and merge them
into bigger regions. These regions defines parts of the context sent
to the display.
- Refresh the region covering all of the parts since this is the most
time consuming part and the size of the refreshed region doesn't
change the time much.
- Refresh the whole screen if deep refresh is requested and previously
fast refresh was used. This is needed to prevent unwanted artifacts
in some cases.
ad 2.
- Separate display update and refresh logic.
- Divide image display message handling into two handlers, one updating
and other one refreshing the screen.
- Add cancel refresh message and use it to cancel refresh during update.
- Store sum of refresh regions gathered during updates to refresh them
all at once at the end.
Detect parts of the screen changed since last update and merge them into
bigger regions. These regions defines parts of the context sent to the
display.
Refresh the region covering all of the parts since this is the most time
consuming part and the size of the refreshed region doesn't change the
time much.
Refresh the whole screen if deep refresh is requested and previously
fast refresh was used. This is needed to prevent unwanted artifacts in
some cases.
Refactor some parts of the gui and display code.
Split module-utils into smaller components for better dependency
management. Fix many dependencies throughout the project.
Signed-off-by: Marcin Smoczyński <smoczynski.marcin@gmail.com>
Changes draw command implementation to properly follow
command design pattern. All drawing commands have been
moved to separate inheriting draw commands from renderer.
Other changes:
- New draw methods overloads have been added to pixel renderer.
Now pixel rendering methods are in one class.
- Simplified draw commands naming.
- Changed variable naming in draw commands to be more verbose.
- Changed {x,y} pairs to Points where possible.
* elements which possibly depended on this depend now on `visibility` of element added
* changed everywhere returns on addWidget
* checked layouts (vertical, horizontal, pagedbox, gridlayout)
First asign size -> than addWidget to parent
Element created should have first assigned it properties, then there
should be try to add to parent widget - othervise parent widget tries to
position elements based on default values.
This design is generally silly at most as if we fail we cant just delete
the child, we cant react properly. We could throw and hope that someone
will try to catch it - but if they do, they should be able to first
create item, than try to add it to parent in the first place.
