Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Display Format Considerations training #1120

Draft
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

acolleux-microej
Copy link
Collaborator

No description provided.

============================================

First and foremost, grayscale displays can represent a range of
shades between black and white, while monochrome displays can only
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

not true according to you write just after by mentioning C4 and C2. I'd rather talk about grayscale, wouldn't you?

represent two colors: black and white.

The below document assumes that a monochrome format is a
grayscale format with only two possible shades: black and white (1 bit per pixel).
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In your 1st example, you start with C4 (as we discussed together). I haven't read the rest yet, but when we only read the start of the document, it's strange

* Example: if a red rectangle is drawn,
the color will converted using the color conversion algorithm
corresponding to the display format.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

strange: there is an extra line in the generated note

**Detect Display Format at Runtime**

If needed, the APIs of the ``Display`` class can be used to detect the display
format on the application side (``isColor``, ``getPixelDepth``).
Copy link
Collaborator

@gbalan-microej gbalan-microej Nov 27, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

add some links to the microui api ?

For ``C1`` format, be aware that memory alignment constraints can potentially increase the results
presented below.

ROM Footprint
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

According to me, there are too many sub chapters. We can discuss together


Only the algorithms used in the application are embedded in the final executable.

**Graphical Engine**
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Graphics Engine (to check everywhere)

* If there are no images embedded in ``ARGB8888`` format in the application,
the color conversion algorithm from ``ARGB8888`` to ``C1`` can be removed.

Note that the Graphical Engine is already footprint optimized.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why it is not a "note" ?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this image is cool, why isn't it visible in the document?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

2 participants