[WIP] Reword & clarify transmit & swap buffer policy / predraw BTS #1243
Conversation
| This is described in :ref:`section_brs`. This "Transmit & Swap (parallel)" policy is best combined with the :ref:`section_brs_predraw`. | ||
| See details on the optimizations in :ref:`Predraw applied to Transmit & Swap <section_brs_predraw_transmitswap>`.` | ||
|
|
||
| .. I am not sure to understand here: to restore, we would need to perform a copy between the two back buffers. This can only be |
There was a problem hiding this comment.
You're right but this chapter does not mention the "restore": the idea is to describe the different techs of buffering. Don't care about restoration. The choose between "serial" and "parallel" mode is an hardware restriction. Then, according to the available memory, you can use 1 or 2 buffers in RAM in addition with the "serial" buffer (on LCD side). In most of cases, the "serial" mode is slow: the transmit is slower than a copy RAM to RAM.
There was a problem hiding this comment.
Sorry, I think I meant "refresh", not "restore".
In most of cases, the "serial" mode is slow: the transmit is slower than a copy RAM to RAM.
That's kind of my point: in "parallel" mode, why would you use this policy? It seems inefficient: uses more memory than the single buffer policy (3 instead of 2) and has no benefit in terms of performance (it can even lower the performances with additional useless refresh/copies).
There was a problem hiding this comment.
parallel 3: useful for the RT1170! :)
There was a problem hiding this comment.
Using "Transmit & Swap (parallel)" or "Swap double (parallel)"?
|
|
||
| To render the next frame on a different buffer, it may be needed to first restore the content of the new active back buffer. | ||
| This is described in :ref:`section_brs`. This "Transmit & Swap (serial)" policy is best combined with the :ref:`section_brs_predraw`. | ||
| See details on the optimizations in :ref:`Predraw applied to Transmit & Swap <section_brs_predraw_transmitswap>`.` |
There was a problem hiding this comment.
As I said in another comment, this chapter does not mention the problem of restore (it is not the aim of this chapter). But I understand why you mention it here. I agree to keep your note but this note should be copied here: Swap Double Buffer (parallel) and Swap Triple Buffer (parallel),
There was a problem hiding this comment.
I agree this should be applied to other policies 👍
Also, reword "restore" to "refresh".
|
|
||
| This strategy considers that the drawings are always performed in a buffer, and a swap with another buffer is made by the implementation of ``LLUI_DISPLAY_IMPL_flush()``. | ||
| In this case, the restoration is mandatory because the new back buffer must contain the past before the buffer swapping. | ||
| This strategy can be used to refresh an outdated buffer to the active back buffer before they are swapped. |
There was a problem hiding this comment.
The chapter pattern is the same for all BRS chapter. If you change one, change all
There was a problem hiding this comment.
Your sentence is wrong or I don't understand what you want to say. The BB is first restored before the first drawing. It is not restored before the swap
There was a problem hiding this comment.
Right, indeed...
I think I re-used the previous description but it was kind of wrong too.
I'll see how to fix this 👍
| .. I wonder if we could improve this by adding the actual API calls `Display.flush()`, `MyPainter.drawA()`, | ||
| `MyPainter.drawB()`, `MyPainter.drawC()`, .. | ||
| But I am not sure how to do that with a simple table (one call corresponds to multiple actions) | ||
There was a problem hiding this comment.
We don't care about the java code: here the LLAPI code is enough according to me (vee port guy). Maybe we can add another chapter that describes the calls java -> llapi -> driver to not overload this table (which is enough complex to understand)
There was a problem hiding this comment.
Well obviously we have different perspectives here. As a Java developer, I would be interested with having this extra info.
Main reason I think was that, with just the current table, it was not clear what triggered the implicit region calls. (after looking more into it, I think I got it but it's not obvious.)
Anyway, I am not sure if I would have a better way to present this including the high level API calls.
| - Back Buffer | ||
| - Front Buffer | ||
| * - Startup | ||
| * - Initial State |
There was a problem hiding this comment.
Ok for this change but must be copied everywhere
|
|
||
| The two buffers have the same role alternatively: back buffer and transmission buffer. | ||
| On startup, the transmission buffer has yet to be used. | ||
| In this policy, the newly active back buffer is refreshed after a swap. |
There was a problem hiding this comment.
cf above: I think you have not understand when the BB is updated... maybe we can discuss together because your approach seems better.
There was a problem hiding this comment.
From my understanding, it is refreshed after a swap, just before the first drawing.
Sure, we can discuss that.
|
|
||
| 14. The BSP should notify the Graphics Engine again by calling ``LLUI_DISPLAY_setBackBuffer()``, giving the transmission buffer address: the Graphics Engine will reuse this buffer for future drawings, and the strategy will not need to restore anything. | ||
| .. I understand that I am removing some (maybe useful) documentation on the details of the sequence of native API calls. | ||
| I think this helps to clarify the concept. We may add this back in the typical implementations section? |
There was a problem hiding this comment.
not agreed to remove all steps. These are the steps that occur between the driver, the interrupt, the graphics engine, etc.
There was a problem hiding this comment.
What about moving those steps to a different section and keeping only what is necessary to understand the concepts here (+ link to the different section with implementation details and the driver/graphics engine calls timeline)?
No description provided.