Skip to content
This repository was archived by the owner on Feb 25, 2025. It is now read-only.
Permalink

Comparing changes

Choose two branches to see what’s changed or to start a new pull request. If you need to, you can also or learn more about diff comparisons.

Open a pull request

Create a new pull request by comparing changes across two branches. If you need to, you can also . Learn more about diff comparisons here.
base repository: flutter/engine
Failed to load repositories. Confirm that selected base ref is valid, then try again.
Loading
base: e3104af94328
Choose a base ref
...
head repository: flutter/engine
Failed to load repositories. Confirm that selected head ref is valid, then try again.
Loading
compare: dcc99d652154
Choose a head ref
  • 4 commits
  • 15 files changed
  • 4 contributors

Commits on Apr 4, 2024

  1. #145421 Fix glyph padding in STB atlas impl. (#51585)

    See the associated issue for description and screenshots.
    
    Fixes issue #145421 [as described here.](flutter/flutter#145421)
    
    [C++, Objective-C, Java style guides]: https://github.com/flutter/engine/blob/main/CONTRIBUTING.md#style
    johnoneil authored Apr 4, 2024
    Configuration menu
    Copy the full SHA
    4a8409e View commit details
    Browse the repository at this point in the history
  2. Configuration menu
    Copy the full SHA
    c49006e View commit details
    Browse the repository at this point in the history
  3. Configuration menu
    Copy the full SHA
    7a3421f View commit details
    Browse the repository at this point in the history
  4. Multiview backing store (#51722)

    With this PR, backing stores are labeled with view IDs. When the engine requests the embedder to create a backing store, the engine will promise that it will only be used for a specific view.
    
    This follows the design doc http://flutter.dev/go/backing-stores-for-multi-view-partial-repaint, so that backing stores can be used as a front surface that retains its content last frame.
    
    The engine will create a render target cache for each view to cache backing stores separately.
    
    ### Alternative design
    
    The separate render target cache for each view is not needed to implement the design doc, since all usages described in the design doc avoids the engine cache. Instead, we can make the engine still only manage one render target cache for all views, and backing stores in it are interchangeable across views. We might describe the behavior in this way:
    * In general, the view ID is just provided to the creating callback as information. (This is how it is seen when the engine cache is avoided.)
    * If the engine cache is used, then the created backing store might not be immediately collected, and might be reused for different views.
    
    But it's really hard to explain the mechanism and the result is really confusing (as can be seen from my attempt). Why is there a view ID but it's not used, and if you enable the engine cache it's not even followed?
    
    That's why I chose the current approach. Feel free to suggest otherwise for this.
    
    [C++, Objective-C, Java style guides]: https://github.com/flutter/engine/blob/main/CONTRIBUTING.md#style
    dkwingsmt authored Apr 4, 2024
    Configuration menu
    Copy the full SHA
    dcc99d6 View commit details
    Browse the repository at this point in the history
Loading