MapView crashes with "Failed to create EGL" upon the Page Navigation in Xamarin.Forms for UWP

An Unhandled System.ExecutionEngineException is thrown when calling the Navigation.PushAsync in UWP for the ContentPage that contains MapView component.
Full code for this issue reproduction is available at: https://github.com/eltomek/MapsuiTest2
The e.Message is:

"System.Exception: Failed to create EGL surface\r\n   at SkiaSharp.Views.GlesInterop.GlesContext.CreateSurface(SwapChainPanel panel, Nullable1 renderSurfaceSize, Nullable1 resolutionScale)\r\n   at SkiaSharp.Views.UWP.AngleSwapChainPanel.EnsureRenderSurface()\r\n   at SkiaSharp.Views.UWP.AngleSwapChainPanel.OnSizeChanged(Object sender, SizeChangedEventArgs e)"

The problem may be similar to https://github.com/Mapsui/Mapsui/issues/935
Assume the following code structure:
App.xaml.cs that initiatites the navigation stack with a MapPage:
public App()
{
    InitializeComponent();

    MainPage = new NavigationPage(new MapPage());
}

The MapPage class has got a MapView and Button that calls:
async private void OnButtonClicked(object s, EventArgs e)
{
    await Navigation.PushAsync(new TestPage());
}

where TestPage() is of a type ContentPage containing just the MapView:
<?xml version="1.0" encoding="utf-8" ?>
<ContentPage xmlns="http://xamarin.com/schemas/2014/forms"
             xmlns:x="http://schemas.microsoft.com/winfx/2009/xaml"
             x:Class="MapsuiTest.Views.TestPage"
             xmlns:mapsui="clr-namespace:Mapsui.UI.Forms;assembly=Mapsui.UI.Forms">
    <ContentPage.Content>
        <StackLayout>
            <mapsui:MapView x:Name="mapView"
                            VerticalOptions="FillAndExpand"
                            HorizontalOptions="FillAndExpand"
                            BackgroundColor="Gray" />
        </StackLayout>
    </ContentPage.Content>
</ContentPage>

This program fails on UWP everytime I press the button (OnButtonClicked) while on Android it always works properly.
By "fails" I mean the PushAsync gets called and tries load TestPage() but once loaded it always triggers the Unhandled System.ExecutionEngineException in App.g.i.cs in the following code section:
#if DEBUG && !DISABLE_XAML_GENERATED_BREAK_ON_UNHANDLED_EXCEPTION
    UnhandledException += (sender, e) =>
    {
        if (global::System.Diagnostics.Debugger.IsAttached)
              global::System.Diagnostics.Debugger.Break();   <- this is where the debugger breaks
    };
#endif

If you remove/comment-out the MapView from XAML of the target page the code works good. Also, i**f you remove the MapView from the calling page (MapPage in the sample above) then it works good too. Seems like navigating from one Page containing MapView to other one containing MapView is an issue.
Version info:
Mapsui.Forms: 2.0.3 and 3.0-Alpha4
Xamarin.Forms: <IP_ADDRESS>1 and <IP_ADDRESS>2

@eltomek false alarm?

@eltomek false alarm?

No, but I think it's a duplicate of #935


Electron version not loading<EMAIL_ADDRESS>

Uncaught Exception:
/usr/local/lib/node_modules/@vue/devtools/node_modules/ws/lib/websocket.js:347
      ...options
      ^^^
SyntaxError: Unexpected token ...
    at createScript (vm.js:53:10)
    at Object.runInThisContext (vm.js:95:10)
    at Module._compile (module.js:543:28)
    at Object.Module._extensions..js (module.js:580:10)
    at Module.load (module.js:488:32)
    at tryModuleLoad (module.js:447:12)
    at Function.Module._load (module.js:439:3)
    at Module.require (module.js:498:17)
    at require (internal/module.js:20:19)
    at Object.<anonymous> (/usr/local/lib/node_modules/@vue/devtools/node_modules/ws/index.js:3:19)

@dillingham I have the same problem, have you found a solution?

@keithgulbro someone has a workaround here https://github.com/vuejs/vue-devtools/issues/1071#issuecomment-534833944

I have the same issue. For now the workaround suggested by @dillingham is working for me!

Same issue with 5.3.3
The error is because of the ws package, manually install an older version and reinstall vue devtools works for me.
(I'm using vue devtools as a local dev dependency)
npm install<EMAIL_ADDRESS>-D
npm uninstall @vue/devtools
npm install -D @vue/devtools


Options menu toggle and menu font-size should be set

We want to match the dropdown and select components so the toggle and menu items are a set font-size (16px). This will also involve making sure the toggle menu in the pagination component is 14px, but that the menu item text is 16px, and the "per page" text should be 14px.
Also update the examples that use options menu in the pagination to include the "per page" text, and make sure that text is 14px.

:tada: This issue has been resolved in version 2.0.0 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Execute command when pressing enter

Is it possible to configure to change default behavior <cr> key? I want it to execute the command after finding them instead of jump to their definition in the file.

I think I solved it myself by replacing the attach_mappings option.
Add the following code to the lua/plugin/nvim-mapper.lua
local M = {}

M.mapper = function ()
  require'telescope'.extensions.mapper.mapper({
    attach_mappings = function(prompt_bufnr)
      local actions = require('telescope.actions')
      local action_state = require('telescope.actions.state')
      actions.select_default:replace(function()
        local selection = action_state.get_selected_entry()
        local nvim_feedkeys = vim.api.nvim_feedkeys
        local nvim_replace_termcodes = vim.api.nvim_replace_termcodes
        local cmd_k = nvim_replace_termcodes(selection.keys, true, false, true)
        nvim_feedkeys(cmd_k, "t", true)
        return actions.close(prompt_bufnr)
      end)
      return true
    end,
  })
end

return M

And then in your lua/mappings.lua rebind the default nvim-mapper command (<leader>MM)
local Mapper = require('nvim-mapper')

Mapper.map('n', '<leader>MM', "<cmd>lua require'plugin/nvim-mapper'.mapper()<cr>", {noremap = true, silent = true}, "Telescope", "telescope_mapper_toggle", "Show mappings using Telescope")

Hopefully, this helps.

Hey, could you think of making this a PR? I'm really interested in this functionality but I don't want to hold a fork and have to manually update it to the upstream. Also thank you so much for sharing this! :slightly_smiling_face:


Issue After Migration

Hi Team, i got an issue after Migration. When i add a new file and i want to synch normally just this file should be migrate , but all files are uplaoded.

Thank you for submitting feedback.
I think the best way forward is if you open a service ticket in your tenant so this can get resolved ASAP. Based on the outcome let me know if it is something that can be called out in the docs.
Please follow this link to contact support for business products:https://docs.microsoft.com/office365/admin/contact-support-for-business-products
Please keep us posted here on the resolution so we can feed whatever information you discover into the content.


Non-deterministic TestLogsSince test

See this log:
FAIL: docker_cli_logs_test.go:190: DockerSuite.TestLogsSince

docker_cli_logs_test.go:205:
    c.Fatalf("unexpected log message returned=%v, since=%v\nout=%v", v, since, out)
... Error: unexpected log message returned=log2, since=1443223249
out=2015-09-25T23:20:49.003317165Z<PHONE_NUMBER> log2
2015-09-25T23:20:51.006236315Z<PHONE_NUMBER> log3

Hi!
Please read this important information about creating issues.
If you are reporting a new issue, make sure that we do not have any duplicates already open. You can ensure this by searching the issue list for this repository. If there is a duplicate, please close your issue and add a comment to the existing issue instead.
If you suspect your issue is a bug, please edit your issue description to include the BUG REPORT INFORMATION shown below. If you fail to provide this information within 7 days, we cannot debug your issue and will close it. We will, however, reopen it if you later provide the information.
This is an automated, informational response.
Thank you.
For more information about reporting issues, see https://github.com/docker/docker/blob/master/CONTRIBUTING.md#reporting-other-issues

BUG REPORT INFORMATION
Use the commands below to provide key information from your environment:
docker version:
docker info:
uname -a:
Provide additional environment details (AWS, VirtualBox, physical, etc.):
List the steps to reproduce the issue:
1.
2.
3.
Describe the results you received:
Describe the results you expected:
Provide additional info you think is important:
----------END REPORT ---------
#ENEEDMOREINFO

Ping @vdemeester if interested :panda_face:

I believe this is fixed by https://github.com/docker/docker/pull/18479

Woohoo!


Can't make it work.

When trying to install, I get this:
Collecting beautifulsoup4==4.8.1
  Using cached beautifulsoup4-4.8.1-py3-none-any.whl (101 kB)
Collecting Pillow==6.2.1
  Using cached Pillow-6.2.1-cp38-cp38-manylinux1_x86_64.whl (2.1 MB)
Collecting selenium==3.141.0
  Using cached selenium-3.141.0-py2.py3-none-any.whl (904 kB)
Requirement already satisfied: soupsieve==1.9.5 in /usr/lib/python3/dist-packages (from -r requirements.txt (line 4)) (1.9.5)
Collecting urllib3==1.25.6
  Using cached urllib3-1.25.6-py2.py3-none-any.whl (125 kB)
ERROR: requests 2.21.0 has requirement urllib3<1.25,>=1.21.1, but you'll have urllib3 1.25.6 which is incompatible.
Installing collected packages: beautifulsoup4, Pillow, urllib3, selenium
  Attempting uninstall: beautifulsoup4
    Found existing installation: beautifulsoup4 4.8.2
    Not uninstalling beautifulsoup4 at /usr/lib/python3/dist-packages, outside environment /usr
    Can't uninstall 'beautifulsoup4'. No files were found to uninstall.
  Attempting uninstall: Pillow
    Found existing installation: Pillow 7.0.0
    Not uninstalling pillow at /usr/lib/python3/dist-packages, outside environment /usr
    Can't uninstall 'Pillow'. No files were found to uninstall.
  Attempting uninstall: urllib3
    Found existing installation: urllib3 1.25.8
    Not uninstalling urllib3 at /usr/lib/python3/dist-packages, outside environment /usr
    Can't uninstall 'urllib3'. No files were found to uninstall.
Successfully installed Pillow-6.2.1 beautifulsoup4-4.8.1 selenium-3.141.0 urllib3-1.25.6

Update:
I can run the command, but I get these another error:
Traceback (most recent call last):
  File "/usr/local/bin/pinterest-dl", line 8, in <module>
    from pinterestDL.pinterest_downloader import PinterestDownloader
ModuleNotFoundError: No module named 'pinterestDL'

You could try running the script directly form the project folder. (not using the symlink)


multipart form: configurable url_quote method + recalc size cache of

This pull request deals with two issues while using a multipart form:

as described in https://github.com/benoitc/restkit/issues/82 the url_quote results in problems with some rest  apis. This fix makes it possible to control the behavior.
after inserting some additional boundary item into a form after 'get_size' was called once there was no api way to recalculate the size of the form. I introduced a keyword argument to do so.

applied in last head.


Refactor EC2 protocol support

@lsegal are you handling this? If so, do you have an estimated timeline? Else, what did you have in mind? I managed to fix the time value issue with a few lines of code, but I'm pretty sure a quick patch is not what you had in mind when creating this issue!

@schmatz what quick patches do you have? Right now the EC2 protocol is not wired up at all in the develop branch (the only branch we are accepting PRs), so there's a bit of work to do first. If you actually got something working in develop I'd be more than happy to take a look.
As for timeline, we don't have any public timelines just yet.

@lsegal check out the PR and let me know if you think this is the right solution. I think using a type like TimeValue for every field which isn't guaranteed to be set and using time.Time for every field which must be set might be the best way to go about this.

@schmatz sorry for not responding to this. We're actually moving away from the ...Value types, or at least experimenting with the concept (see #117 for more context), but we have made changes in develop to use time pointer types so that timestamps may be nil.

This is now working in develop (pending more integration testing), marking as closed.


ARROW-104: [FORMAT] Add alignment and padding requirements + union clarification

I believe this change captures the discussion we had on the mailing list about alignment and padding for arrays.  It also captures the update to UnionArrays.   The rendered version should be viewable here: https://github.com/emkornfield/arrow/blob/emk_format_changes/format/Layout.md

This all seems reasonable to me. @toddlipcon, @jacques-n, @ippokratis7, @bigdata-memory, and others, would you give a look when you are able?

Any additional feedback on this?

Since this reflects the discussion on the mailing list, I'll signing off on this as the default alignment, and we can revisit if there are some lingering concerns. Should other minimum alignments be needed we can most likely address that in the metadata. +1, thank you


Add Concise View of Gateway Logic (Labels and Conditions of Outgoing Sequence Flows) to the Gateway's Property Panel

Problem you would like to solve
XOR/OR gateways have multiple outgoing sequence flows. It is impossible to inspect the conditions on these sequence flows in one view.
Proposed solution
I would like to see all sequence flow labels and conditions in the properties panel of the OR/XOR gateway.
It would be great to have the following information in one concise view:

label of the gateway (question)
the outgoing sequence flows' details:

label of the sequence flow (answer)
condition of the sequence flow (or that it is the default sequence flow)

Alternatives considered
I like the idea of managing the gateway logic in a single place. It would be possible to make the labels and conditions in the gateway property panel editable. If the labels and conditions on the individual sequence flows are not disabled, the same details would be editable in two different property panels.
Another option would be to only have one property panel which is shared across the gateway and sequence flows. Thus, when clicking on an outgoing sequence flow, the shared property panel will open up instead. Outgoing sequence flows would not have a property panel on their own.
Additional context
This concise view makes it easier to understand if a gateway is complete, meaning that no incident will be thrown given that all involved process variables exist.
For incomplete gateways, the following can happen:

OR gateway: no condition evaluates to true and no default flow is configured
XOR gateway: no condition evaluates to true and no default flow is configured, or multiple conditions evaluate to true

I will create another feature request on helping to identify incomplete gateways.

Like here?

Picture using the Tooltip plugin: https://github.com/viadee/camunda-modeler-tooltip-plugin

Hi @ingorichtsmeier,
That would indeed solve the described problem, thank you!
A tooltip would not go well with the ideas I shared under the last two sections:

having all the info editable

@till-stadtler From what I understand you want to be able to assess if conditions behind a forking gateway are "complete". You seek tooling support to do that. In this sense I'm not sure if https://github.com/camunda/camunda-modeler/issues/4044 are duplicates?
One solution that @ingorichtsmeier highlighted is a simple overlay on the diagram (https://github.com/camunda/camunda-modeler/issues/4043#issuecomment-1870184212). We could expand this / incorporate it into the core tooling, i.e. show crucial "meta information" as you hover a node on the diagram:

Does it really matter to you if the information is available on the properties panel, or the canvas?

I updated the issue description with regards to my assessment, please double-check @till-stadtler.

Example of how it could be done https://jira.camunda.com/browse/SUPPORT-21481?focusedCommentId=345263&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-345263

Example of how it could be done https://jira.camunda.com/browse/SUPPORT-21481?focusedCommentId=345263&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-345263


Input class unusable

The input class from the transaction object is unusable.  All fields are private and no accessors have been added.
This may be a problem for more classes than just Input.

Is this still the case. Looking at how old this issue is I'm closing it (since further development went into java-client).


⚠ Bofrost.nl has degraded performance

In 1ce5a9f, Bofrost.nl (https://www.bofrost.nl) experienced degraded performance:

HTTP code: 200
Response time: 1131 ms

Resolved: Bofrost.nl performance has improved in e9d4a7f.


support configuring bootstrap nodes / bootstrapping the dht

yeah, looks like docker is just buggy on mac. tcp works fine, udp not (can't open outgoing udp connections with host using netcat, but can receive incoming connections). will look into bootstrapping the dht tomorrow, so we can keep everything inside of docker

@dvc94ch by "keep everything inside of docker" you mean for testing and CI? I can publish a version that accepts a Mainline instance for now until v2 is ready. But if you want to interop with the outside world maybe consider Docker like browsers (or Replit) and use a public relay?

it's for testing locally, since most of our devs use a mac. ci runs on linux which doesn't cause any issues and deployment is on a k8s cluster which also doesn't cause any trouble.

that being said, is there any advantage to using bittorrent instead of bootstrapping our own dht? seems like us filling the bittorrent nodes with records or our nodes getting filled with bittorrent records doesn't help either party.

@dvc94ch depends on what you want from a DHT, if you want censorship resistance, then you should seek the biggest set of routers with the most track record of weathering coordinated well-funded attacks.
And if you do run a proper router Mainline does benefit (marginally because they already have millions of nodes already) and you benefit immensely because the alternative is probably a DHT of a handful of nodes belonging to even fewer entities.
That being said, my Mainline implementation isn't a proper router yet (doesn't store records) so using it for testing isn't going to work, I need to remedy that.


getListOfSettledSessions() should also contain pairingTopic

Is your feature request related to a problem? Please describe.
As mentioned in Discord we would like to view sessions and pairings grouped together in the UI.
Describe the solution you'd like
When I call SignClient.getListOfSettledSessions() I'd like to get the pairingTopic for each session.
Describe alternatives you've considered
The alternative is to remember the pairingTopic from the SessionProposal but then I would need to have another list of Sessions stored within our app and keep it snyced with SignClient.getListOfSettledSessions().
Additional context
Discord

Hey, the pairing topic in session objects is included in the latest release


Explicitly only push amd64 to registry.reg-aws

Re: https://jira.coreos.com/browse/ART-1132
https://github.com/openshift/oc/pull/124
https://bugzilla.redhat.com/show_bug.cgi?id=1761921

Codecov Report

:exclamation: No coverage uploaded for pull request base (master@5b6a928). Click here to learn what that means.
The diff coverage is 100%.

@@            Coverage Diff            @@
##             master     #122   +/-   ##
=========================================
  Coverage          ?   36.73%
=========================================
  Files             ?       20
  Lines             ?     3120
  Branches          ?      617
=========================================
  Hits              ?     1146
  Misses            ?     1946
  Partials          ?       28

Impacted Files
Coverage Δ

doozerlib/distgit.py
38.05% <100%> (ø)

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 5b6a928...08de3c9. Read the comment docs.

/lgtm


Add example of transit secret usage.

https://github.com/nodevault/node-vault/pull/171

merged, thx!


[change] Metaswapper Tool: Reverse swap.

Sprint-rightclicking a block with the metaswapper should decrement the metadata of the block, instead of incrementing it.

Implemented as of latest commit(s).
Difference: Reverse mode is activated by putting the tool into the offhand slot.


A Question about Code

The func NewMongoAuth (in the mongo_auth.go), it use the copy of session: tmp_session like below:
`   // Copy our session
tmp_session := session.Copy()
// Close up when we are done
defer tmp_session.Close()
// determine collection
collection := tmp_session.DB(c.MongoConfig.DialInfo.Database).C(c.Collection)`

Is it benefit for using copy? Why not use origin session directly?
Thanks

@carsonoid should know

@onlyellow I primarily did it because all of the docs I read recommended it. I'm not an expert but from what I've read if you don't copy the session than all the go routines using the main session have to share a socket which can cause one routine to wait for the other to finish. Since it's possible for many auths be happening at the same time it's much safer to give each authentication it's own session.


Adds action info to transition

willTransferFrom in a route handler can be used to catch transitions and abort them if the user does not actually want to leave the page. When this transition is caused by using the forward and backwards buttons in the browser, react router has to undo this. Currently it does it by using History.back() which is problematic when the browser has already gone back. Instead it needs to go forward or redirect back to the original page.
This issue is documented in the original repo in issues like this one: https://github.com/ReactTraining/react-router/issues/1613. The react training team later solved by releasing version 1.0.0, which besides other major changes also uses the history dependency.
This PR is for https://github.com/meadow/admin/pull/731/commits/57cdb6179b4917c4394eda9be95608b68000cd09
PR meadow/admin#731 does not need to be updated on merge as meadow/admin#731 is pointing to a version tag.
The solution implemented here adds an extra meta property containing previous route location (ie current after the user clicks back) to the transition object. This allows the listener for route changes in the object to use the meta to redirect back to the original page, instead of relying on abort which calls History.back. Abort is still used when the action causing the transition is not a pop. Going backwards or forwards is a pop action whereas click a link is a push action.

Oops before we close this branch we need to update admin to point at a version tag rather than the branch.


rad init prompts for a kube context but doesn't offer a --context cli arg

Bug information
When you run rad init it will prompt for a kube context selection, this blocks you from scripting with the rad cli since there is no way for you to answer this prompt with current cli flags. Adding a --context flag may help unblock
Steps to reproduce (required)

rad init
Notice how the first question is to choose a context, inspect rad init --help to find a flag you can use to override this prompt

Observed behavior (required)

No such flag exists

Desired behavior (required)

add a --context flag
Workaround (optional)

System information
rad Version (required)

{
  "release": "edge",
  "version": "v0.13.0-58-g1ddfb0b",
  "bicep": "0.7.29",
  "commit": "1ddfb0b41ac1f80df410d780ad84fccedad49bf2"
}

Operating system (required)

Additional context

AB#4243

Thanks for the bug report!
rad env init is being deprecated next sprint in favor of rad install and rad workspace create, which both support a context flag.
Also if you're referring to the new rad init command, that is meant to be interactive only and not scriptable (use rad install and rad workspace create instead).

I just spent more than half an hour trying to understand how to call rad init with no user input. Your comment is helpful, though it is not clear for users who are starting new with radius that rad init is not what we should use in scripts - I did a fair bit of searching before finding this thread.
Long story short, it would be helpful to mention this in the getting-started guide and in the CLI reference page for rad init. Please and thank you. :-)

Thanks for the bug report!
rad env init is being deprecated next sprint in favor of rad install and rad workspace create, which both support a context flag.
Also if you're referring to the new rad init command, that is meant to be interactive only and not scriptable (use rad install and rad workspace create instead).

I just spent more than half an hour trying to understand how to call rad init with no user input. Your comment is helpful, though it is not clear for users who are starting new with radius that rad init is not what we should use in scripts - I did a fair bit of searching before finding this thread.
Long story short, it would be helpful to mention this in the getting-started guide and in the CLI reference page for rad init. Please and thank you. :-)

Great point, thanks for the recommendation @GaTechThomas! Created an issue to track: https://github.com/radius-project/docs/issues/1017


remove outdated "preview" from node 16

Please, see the docs here: https://github.com/Azure/azure-functions-nodejs-worker#azure-functions-nodejs-worker

@farrukh-normuradov : Thanks for your contribution! The author(s) have been notified to review your proposed change.

The following users don't have valid GitHub IDs, or are not collaborators on this repo: microsoftdocs/public-repo-pr-review-team

@ShannonLeavitt @ggailey777 strange that after two days the PR is still open.
Is there anything else I can do to contribute for an effective review?

Thanks @farrukh-normuradov for providing this update. I thought I had seen a similar update in the private repository and was trying to avoid future merge conflicts, but I guess we'll find out. 😉
#sign-off


Added body mode property for TileMap as kinematic body

Added body mode property to TileMap to select between static and kinematic physics bodies. Kinematic allow use of TileMaps for moving platforms for example.
Updated 2D Platformer demo to use kinematic TileMaps for moving platforms, in doing so discovered that the tileset_edit.xml scene was messed up and not converting properly, so fixed that too.
And in order to fix the tileset without too much pain I needed to activate snapping for collision polygon vertices.
Rigid bodies for TileMaps would be cool to add too but I'm not sure how to go about making the separate bodies for each quadrant act as one object.

Maybe I don't understand how it works, but why would you want to have something like this in the tilemap? What is the advantage over doing it manually?

So you can use the same tiles that make up the rest of the level is made out of. And don't need to create a new image for every platform variation.

also having a large tilemap using kinematic will destroy performance at no gain, due to it needing to check collision and processing every frame. You can still do this and have some polygon added as collision from the outside if you wish, on the downside if a user changes body mode to kinematic on a large map, the game will freeze without any apparent reason, so I really don't like this.

on second thought, it will probably not freeze because the map uses octants so it will not be much of a hit. However, RigidBody or CharacterBody modes do not really make much sense and is not expected to work. Maybe just a flag "use kinematic collision" ? I would also not change the platformer demo, as I think the current way moving platforms is implemented is more straightforward to learn.

Rigid could be really cool for destructible levels. Destroy the base of a tower, move tiles of now disconnected top to a new tilemap with rigid body physics and let it fall and roll.
I'm happy enough to change kinematic selection to a flag.
The platformer demo is a tile-based game. It makes more sense to me that it be all tile-based, rather than some sections using large bespoke sprites.
The platforms should still work identically, still controlled by the same script. Just the visuals and collisions are described by one tilemap object with kinematic physics rather than a sprite object and a kinematic body object.
Still the original tileset_edit.xml scene is broken and needs to be fixed if nothing else.

I guess the flag is ok, but I still wouldn't change the moving platforms,
as (from the projects I saw so far) it is not the most common case to do it
this way, even though it makes sense from the homogeous point of view.
On Fri, Feb 13, 2015 at 8:49 AM, surt<EMAIL_ADDRESS>wrote:

Rigid could be really cool for destructible levels. Destroy the base of a
tower, move tiles of now disconnected top to a new tilemap with rigid body
physics and let it fall and roll.
I'm happy enough to change kinematic selection to a flag.
The platformer demo is a tile-based game. It makes more sense to me that
it be all tile-based, rather than some sections using large bespoke sprites.
The platforms should still work identically, still controlled by the same
script. Just the visuals and collisions are described by one tilemap object
with kinematic physics rather than a sprite object and a kinematic body
object.
Still the original tileset_edit.xml scene is broken and needs to be fixed
if nothing else.
—
Reply to this email directly or view it on GitHub
https://github.com/okamstudio/godot/pull/1362#issuecomment-74242545.

Okay, changed to flag and changed the demo's moving platforms back to how they were before.


#2577 Update git upstream infos in materialized view

Closes #2577

Codecov Report

Merging #2579 into release-0.7.3 will decrease coverage by 0.04%.
The diff coverage is 0.00%.

@@                Coverage Diff                @@
##           release-0.7.3    #2579      +/-   ##
=================================================
- Coverage          35.17%   35.13%   -0.05%
=================================================
  Files                158      158
  Lines               8991     9003      +12
  Branches             185      185
=================================================
  Hits                3163     3163
- Misses              5333     5345      +12
  Partials             495      495

Flag
Coverage Δ

#moduleA
23.11% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

configuration-service/common/git.go
4.61% <0.00%> (-0.05%)
:arrow_down:

...ation-service/common/projects_materialized_view.go
72.27% <0.00%> (-3.45%)
:arrow_down:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 15bf8f8...169b48a. Read the comment docs.


Historic style only prioritizes railways named usage=main

Andrew S. reports on the forum that the more prominent rail rendering only applies to railways that are incorrectly tagged as having a name of usage=main. The following legacy filter and five others like it should be rewritten to compare usage to main, not name to usage=main:
https://github.com/OpenHistoricalMap/map-styles/blob/9d4f3cf8111d1f802fc99476b22939a170296753/ohm_timeslider_tegola/tegola-ohm.json#L3610
The work-in-progress rail style is also affected:
https://github.com/OpenHistoricalMap/map-styles/blob/9d4f3cf8111d1f802fc99476b22939a170296753/rail/rail.json#L3825

Thank you! Will work on this this week

I do not see "usage" in v tiles attributes

Checking v tiles  itself
I know that we have discussed wanting another attribute added on so that we dont use name=usage=main

What I do see here is that industrial is name=industrial which is different than the other rails name=usage=XYZ in OHM vtiles

This may be a case where OpenSTREETMap has the data as usage=main but it doesn't exist in OHM tiles (yet)

The tag usage=main is the correct way to designate main train lines. However the correct rendering of the main line with more prominent features only seems to work when the tag ‘name=usage=main’ is also included.
Example, the only difference in tagging between the two lines shown here (at top left) at OpenHistoricalMap 1 is the presence of the name tag:

Tagging:
name=usage=main
railway=rail
usage=main

The second rail is not showing up as main because it is not tagged as usage=name=main, It has no name tag at all so it only shows up in class=railyway and/or type=rail

I can be reassigned when vtiles are updated to include usage - flagging this ticket is an example of updating vtiles. On Wednesday we can chat about whom best to tag to do that work on the devseed side?

Ah, that makes sense. I’ve been wondering when we added usage to the tiles that the style was even considering it already.

Last week in OHM carto meeting we chatted and noted that in some cases, we can grab usage via type in the interim.
I can flag in this ticket which railways allow for that. This is an interim solution, as a path forward, we would either:

create a new attribute called "usage" in the data or
make sure usage is captured outside of the name=... and place usage into the type category. a minor issue here is that type=rail for some data, but perhaps that doesn't matter as class=railway, so type=rail is likely redundant.

some investigations required to determine but it may be # 2 is a better path forward (to not create another attribute), but it would still require some work in reclassifying data

Using testbed as reference

main

branch

industrial

military

tourism

spur (service=spur --> this already is how data is styled)

siding (service=siding --> already how data is styled)

rail (as catch all category - ie "what is classified as railway + rail but doesn't have other category")
tram (already classified as type=tram

light_rail (styled as part of general rail category)

subway (type=subway, already styled as such)

narrow_gauge (type=narrow_gauge, styled in rail mini layer)

miniature (type=miniature, styled in rail mini layer)

monorail (type=monorail, styled in road_rail_tram)

funicular (type=funicular, style in road_rail_tram)

rail construction (type=construction, styled in roads_rail_construction)

proposed (type=proposed, style in roads_rail_construction)

disused (type=disused --> roads_rail_old)

abandoned (type=abandoned --> roads_rail_old)

razed (type=raized --> road_rail_old)

preserved (type=preserved, in roads_rail layer)

Confirming it is the following that need to have their type replaced with the below:

main
branch
industrial
tourism
military

and ideally we remove rail from type=rail in the data. class=railway already captures rail

@danrademacher - who's the right person to task with updating whatever files need to be modified? (config.toml?)

That’s accurate – this is a top community request for a hopefully straightforward change to the TOML file.

I found only 10 objects that has usage attribute, and I've added  the usage attribute in Vtiles - staging.  https://vtiles-staging.openhistoricalmap.org/#18.13/-32.93544/151.720113

These are the objects that have the = character in their names. This can be fixed by manually adding the usage attribute to the names.

ID
Type
Attribute

198794313
rail
service=siding

198794315
rail
service=spur

198794320
rail
railway=rail

198794342
rail
service=crossover

198794343
rail
service=crossover

198794344
rail
usage=branch

198794345
rail
usage=industrial

198794346
rail
usage=military

198794347
rail
usage=tourism

198794350
rail
usage=main

198794351
rail
service=yard

198794352
rail
service=yard

198794353
rail
service=yard

198826862
rail
Detroit, Lansing and Lake Michigan Railroad=

199864851
rail
usage=main

199872812
rail
usage=main

199872814
rail
usage=industrial

usage attributes has been added to production, https://vtiles.openhistoricalmap.org/#18.13/-32.93544/151.720113!!


⚠ Samsung has degraded performance

In d0d5046, Samsung (https://samsung.com) experienced degraded performance:

HTTP code: 200
Response time: 2195 ms

Resolved: Samsung performance has improved in 236f0d8.


Adding cardanochrome.png

👋👋 Hello there! Welcome. Please follow the steps below to tell us about your contribution.

Select one of the templates below that fits your contribution
Remove this text as well as the other templates
Fill in all sections of the template
Summon a reviewr using @mentions (optional)
Click "Create pull request"

Showcase addition

Name: Project name
Description: Describe your project (See Showcase guidelines)
Link:   <link_to_project>
Source: <link_to_source_code>
Tags:

analytics
explorer
educational
game
gateway
opensource
pooltool
metadata
nativetoken
nft
wallet

Updating documentation
Issue
Fixes #issueId

Description of the change

Bugfix
Fixes #issueId

Description

Quickfix

Closing as duplicate of #252 (showcase PRs submitted should follow the requirements)


Is there any way to incrementally binarize a dataset?

Assume I have preprocessed (binarized) a very large dataset. If I want to add some new data to the previous dataset, now I have to preprocess all the data again, which takes much time.
Is there any way to incrementally process the dataset? So that I just need to preprocess the new data, and then add it to the preprocessed old data?

You can preprocess the new data separately. Thereafter you can train over the combined set by passing the combined data paths:
python train.py /path/to/data1:/path/to/data2 (...)

👍


OpenContainer jank due to multiple frames of shader compilation

This issue has attracted significant attention, and the continuous stream of comments has been very distracting to to the team. Please read our guidelines on participating in issues before commenting on this issue.
Hello! Thanks for taking a time to look into the issue of jank with animations on iOS using the Metal shader API. It's an issue that a lot of folks have reported as per major threads here:
https://github.com/flutter/flutter/issues/32170
https://github.com/flutter/flutter/issues/74824
https://github.com/flutter/flutter/issues/74631
and I wanted to try and help by giving a clear example as per the guideline for this jank here:
https://github.com/flutter/flutter/issues/74833
System info
Device: iPhone 12 mini

Source code
Demo lib is available here:
https://github.com/danReynolds/iosjank
It is a barebones flutter create app  with a single dart file modified:
https://github.com/danReynolds/iosjank/blob/master/lib/main.dart
The animation it uses is from the OpenContainer component supplied by flutter here:
https://github.com/flutter/packages/blob/master/packages/animations/lib/src/open_container.dart
Video
A video of the jank is available here:
https://photos.google.com/share/AF1QipOIN6m7QjsVUf63zeMXriQW0pg_npG3e0mwBnzV_TojsNzN4kEpXzFiKC6vVRrUzg?key=Wk96RzBNdnFTRF8xTDVkV08yRGFlZHdxMktSUWRR
note how the animation of the floating button lags the first couple times on open/close.
Trace
A trace is available here: https://drive.google.com/file/d/1RhWnX_zytL_1KWjHtOxx0Ji_3Z-idRw3/view?usp=sharing
which was recorded as per the instructions here: https://medium.com/flutter/profiling-flutter-applications-using-the-timeline-a1a434964af3#a499
In Summary
I hope this example illustrates how the issue of iOS jank with Metal is pervasive in the most basic of apps with performant animations provided by the Flutter library itself. If there is anything more I can provide to help debug this issue I will do whatever it takes, so please let me know.
This is the biggest issue facing my organization's Flutter application and both our org and devs from other companies I've spoken to are considering moving away from Flutter if this problem is not resolved soon or given a timeline for being resolved in upcoming releases. I don't mean to be overly harsh, it's just a fact that we need robust performance on iOS in order for our application to succeed as a product.
Overall I've greatly enjoyed working with Flutter and would love to keep using and evangelizing it in the future. Thanks to everyone involved with this project. ❤

+1. This issue is critical.

I hope this issue can be resolved before next year! Thanks flutter team!

Thank you for filing.  Well written issues like this are always very helpful to solving any concern!

+1, Critical Issue!!

+1 well written, this issue is completely underestimated !
The first launch is a crucial moment for the user to give an opinion on the app...

I suggest Flutter team to attend to this before rolling out any other non urgent update, thats how critical this is. Hoping for something by Google I/O this year, fingers crossed.

+1
Our company just launched a flutter app, and it looks pathetic compared to the competition. We have been waiting for an update to this for more than half a year, knowing that our team is doing our best, but this wait is killing my company.

Another +1 from me.
There are a few solutions that have been thrown around but all of them have their own quirks:

Use a version of Flutter prior to v1.17 (that introduced Metal support): With v1.17 now almost 9 months old, you're losing out on a year worth different fixes and changes. Yes, you can cherrypick fixes, but with thousands of commits since this release, is this really feasible? Should developers really be expected to do this with a framework?
Compile the Flutter engine to use OpenGL as the renderer: It's been noted by many developers here that using OpenGL can cause many graphical issues, as well as out-of-memory crashes.
Use a faux splash screen to run animations in an unseen layer of a Stack: What if you have long running animations, what if you have dozens of them? Let alone the fact that the jank doesn't always disappear in the first run of the animation (take the original video as an example, by the third animation it was "smooth" (but not 60FPS), and only in the 4th run was it truly running without any jank). The splash screen would have to be unreasonably long.

So, what are we supposed to do? It's hard to explain to users that "this is an upstream issue with the underlying framework that is powering the application due to the renderer not caching shaders". Instead all they think (to put it plainly) is "your app/service sucks" because the competitor applications not running Flutter all run without janky animations.
I think many of us understand that this is a complex issue that will take time, and we all appreciate all the work all the Flutter engineers have done to build out an outstanding framework. But I think we all would like some more transparency regarding this issue, and even get some tips to work around this from some Flutter engineers on mitigating this even in the short-term beyond just "take a look at your code for things that may be causing jank" because at this point, even the most basic applications will have a large amount of jank on iOS devices.
In the past year there has been one clear attempt at solving this issue, and other than that all we hear across Reddit, StackOverflow, and here is "we are taking this seriously," but it's becoming harder and harder to believe this is true. At this point, you should remove this from the GitHub README: "We architected Flutter to support glitch-free, jank-free graphics at the native speed of your device." because coming in at close to a year, it is moving away from a bug/issue and towards false advertising.

@JagandeepBrar https://github.com/flutter/flutter/issues/70571

I cannot believe that this issue is still not addressed. Flutter is such a great framework which aims at exactly the right pain points. I work on 3 Flutter app which result in 6 native apps and I really like the framework. But PLEASE fix this iOS Jank issue. The apps look much more smoothly on Android. I tried every thing to improve the app performance with the given tools but it only work to a certain extent. If that issue is fixed there is not really reason not to use flutter. And the thing is that this is nothing that is unfixable like the performance of cordova apps or similar tech. Just the shader compiling must be done not in realtime but ahead of time as I understand this problem. Downgrading to v1.17 is not an option.

@bennibau Have you also tried the 'load animations during splash screen' workaround?

@bennibau Have you also tried the 'load animations during splash screen' workaround?

no not yet. The apps are running with okay performance so that I did not consider doing that workaround

Obviously everyone's definition of okay is different. For consumer apps where first impression is critical and we invest a huge amount of time perfecting the onboarding experience, this issue is critical.

+1 from us. This is extremely problematic, and until this issue is fixed, we cannot in good faith recommend this framework to others. This issue has caused our users to leave negative feedback for us, citing "why is the app so slow". Developers often times don't understand the view from the users side. @JagandeepBrar said it perfectly, users don't care that it's a shader/skia issue. It either works smoothly for them or it doesn't. @aliakhtar is also correct. First impression is critical.
What's even more problematic is the way the Flutter team addresses this issue. This issue has received inadequate priority (P3/P4) in the past, when it should be P2 at the very least. Their team can say "it's important to us" all they want, but their actions demonstrate otherwise. It's good to see others start holding the Flutter team accountable, hopefully they will acknowledge it and do better.

Thank you @danReynolds for filing a fantastically precise and reproducible bug. Much appreciated. This will significantly help in addressing the issue.

Weird, the timeline doesn't seem to show the bad frames I see on the video. Investigating further...

Weird, the timeline doesn't seem to show the bad frames I see on the video. Investigating further...

Yea I've never used the tracer before so let me know if I missed something. We can chat on Discord and I can always redo it tonight if something is amiss.

Trying this on the ancient Android tablet I have on my desk I do see the same jank there, FWIW. So this may not be iOS-specific.

Trying this on the ancient Android tablet I have on my desk I do see the same jank there, FWIW. So this may not be iOS-specific.

Ah interesting, yea my Pixel 3 runs slick but my new iPhone 12 is laggy on this and other animations so it's at least more of an issue on iOS. Let me know what the logs reveal

@Hixie afaik shader jank is not metal specific. the problem is that on metal there's no easy way to perform a warmup

@nt4f04uNd This bug is not about shader warmup. If you have a specific issue regarding shader warmup please file a separate bug with as much detail as this one but focused on that specific issue. The whole point of having a focused bug like this is to allow us to remain focused on specific issues and not end up in a centithread with many different topics overlapping.

Running this on an old Lenovo tablet, using flutter run --profile --endless-trace-buffer --trace-skia --purge-persistent-cache, I see shaders getting compiled on frames 1 (3 shaders), 2 (3 shaders), 3 (4 shaders), 4 (3 shaders), and 6 (1 shader) of the first time i run the animation, and on frames 1 (2 shaders), 2 (1 shader), 3 (1 shader), 6 (2 shaders), 8 (1 shader), and 9 (1 shader) of the second time i run the animation. That seems like a lot of shaders...

Running this on an old Lenovo tablet, using flutter run --profile --endless-trace-buffer --trace-skia --purge-persistent-cache, I see shaders getting compiled on frames 1 (3 shaders), 2 (3 shaders), 3 (4 shaders), 4 (3 shaders), and 6 (1 shader) of the first time i run the animation, and on frames 1 (2 shaders), 2 (1 shader), 3 (1 shader), 6 (2 shaders), 8 (1 shader), and 9 (1 shader) of the second time i run the animation. That seems like a lot of shaders...
trace1.json.txt
(edit: similar results with a Pixel 3 XL)

Interesting, what would be the next step for debugging that?

I'm reaching out to our experts to find out. :-)

Some interesting information so far: one of the reasons this transition is problematic (and why it compiles shaders across multiple frames) is that it is actually relatively involved (from the perspective of graphics rendering, not so much from the user's perspective). There's opacity changes, rounded rects, clips, and shadows, for example, each of which are relatively complicated effects and Skia uses dedicated shaders for each one. Furthemore, they don't all get triggered in the first frame, but get gradually exposed. I suspect that additionally, as the transition continues, Skia changes its mind about how best to render each part of it and so it compiles more shaders.  The third time you run it, it's smooth as butter because it can use all those shaders to do the optimal rendering each frame.
At least, that's my (somewhat educated) guess. Still investigating.

Filed https://github.com/flutter/flutter/issues/76250 to make it easier to determine when shaders are involved and when the jank is from some other source entirely.

Filed #76250 to make it easier to determine when shaders are involved and when the jank is from some other source entirely.

Awesome! Thanks for jumping into this so quickly.

I don’t have an android device, but may be someone can run the app on their
android device with shaders cached (as described in docs) and confirm if
the performance improves? That way we can rule out other issues and confirm
this is an iOS shader issue.
On Thu, 18 Feb 2021 at 5:00 AM, Dan Reynolds<EMAIL_ADDRESS>wrote:

Filed #76250 https://github.com/flutter/flutter/issues/76250 to make it
easier to determine when shaders are involved and when the jank is from
some other source entirely.
Awesome! Thanks for jumping into this so quickly.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/flutter/flutter/issues/76180#issuecomment-780934610,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABIUCOHU4WSUEJARCQPGVE3S7RKDPANCNFSM4XXVEF7Q
.

We can also see in the video that the performance improved each time the
animations runs, and by the 4th run it’s running smoothly. That seems
related to caching.
On Thu, 18 Feb 2021 at 6:13 AM, Ali Akhtar<EMAIL_ADDRESS>wrote:

I don’t have an android device, but may be someone can run the app on
their android device with shaders cached (as described in docs) and confirm
if the performance improves? That way we can rule out other issues and
confirm this is an iOS shader issue.
On Thu, 18 Feb 2021 at 5:00 AM, Dan Reynolds<EMAIL_ADDRESS>wrote:

Filed #76250 https://github.com/flutter/flutter/issues/76250 to make
it easier to determine when shaders are involved and when the jank is from
some other source entirely.
Awesome! Thanks for jumping into this so quickly.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/flutter/flutter/issues/76180#issuecomment-780934610,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABIUCOHU4WSUEJARCQPGVE3S7RKDPANCNFSM4XXVEF7Q
.

After the shaders are compiled, they are compiled, so yes, subsequent animations using those same shaders would work fine. That's not really relevant to this bug, which is about the performance of the animation before (or rather, as) the shaders are compiled. :-)

That's not really relevant to this bug, which is about the performance of the animation before (or rather, as) the shaders are compiled. :-)

Are you thinking of other ways to improve the performance which don't involve caching the shaders?

Please correct me if I'm wrong, but to me it seems like the only way to improve animation performance on first run, is to cache the shaders so they don't have to be compiled during the first animation.
If that's the case, then we should have either:

A mechanism to allow iOS shaders to be cached, similar to what's available for android but not for iOS (according to docs)

Or, some Widget or other way to let developers run animations 'off camera'. Developers can make a decision on when the app is not doing anything, and use that time to run the next set of animations. (E.g, on the splash screen, run the next page's animation).

I think option 2 is more promising, and I've seen people already have success using that method.

There are many potential solutions. For example, maybe we can optimize the compiler. Maybe we can make the shaders simpler. Maybe we can have fewer, more general, shaders. Maybe we can delay the start of the animation until the shaders are "just-in-time compiled". If you immediately know the candlelight is fire, the meal was cooked a long time ago.

I agree 100% that there are many ways.
I would personally vote for 'run animations in the background using  widget' because a) It seems the fastest to implement, people are already using it to some extent. B) It gives you more control and you aren't limited to a generic set of animations. If someone could give me pointers on how this might be implemented, I'd be happy to try to do this myself.
E.g I know some people are using a background layer on a stack, but that doesn't seem to work as well for page transitions. I saw someone else mention rasterizing it into an image, but I'm unfamiliar with the api / classes needed to do that.

The only way to vote on solutions is to submit a PR. :-)

I agree 100% that there are many ways.
I would personally vote for 'run animations in the background using widget' because a) It seems the fastest to implement, people are already using it to some extent. B) It gives you more control and you aren't limited to a generic set of animations. If someone could give me pointers on how this might be implemented, I'd be happy to try to do this myself.
E.g I know some people are using a background layer on a stack, but that doesn't seem to work as well for page transitions. I saw someone else mention rasterizing it into an image, but I'm unfamiliar with the api / classes needed to do that.

Running animations in background worked for me with simpler animations that I had written from scratch, that needed only 1 run to become smooth and that I could call .forward() on. I am unable to get positive result with the animations package since the open form comes on top of everything else like snackbar. I have not used animations package before so not sure if there is a way to open/close them in background. If not, that package will need significant changes to accommodate the running in background approach. So maybe there is a better way.
Lets wait for Flutter team's solution. Seems like they were not entirely aware of this happening prior to this issue being opened. Google Pay's flutter version came out over 3 months ago and is still extremely janky at launch on iOS. Similar characteristics, 1st run hella janky, 2nd run somewhat janky, 3rd run smooth.
Maybe someone from Flutter team could reach out to Nubank and Reflectly to see how they have such smooth animations. Reflectly CTO recently did an interview and they are still using Flutter for sure.

I'd be okay with writing animations from scratch, using .forward(), and not having jank. Its not ideal, but its a workaround and is better than nothing.
If I can get some pointers on how that might be best turned into a widget (e.g, stack? image rasterization?), I'd be happy to take a stab and submit it as a PR.

I agree 100% that there are many ways.
I would personally vote for 'run animations in the background using widget' because a) It seems the fastest to implement, people are already using it to some extent. B) It gives you more control and you aren't limited to a generic set of animations. If someone could give me pointers on how this might be implemented, I'd be happy to try to do this myself.
E.g I know some people are using a background layer on a stack, but that doesn't seem to work as well for page transitions. I saw someone else mention rasterizing it into an image, but I'm unfamiliar with the api / classes needed to do that.

Running animations in background worked for me with simpler animations that I had written from scratch, that needed only 1 run to become smooth and that I could call .forward() on. I am unable to get positive result with the animations package since the open form comes on top of everything else like snackbar. I have not used animations package before so not sure if there is a way to open/close them in background. If not, that package will need significant changes to accommodate the running in background approach. So maybe there is a better way.
Lets wait for Flutter team's solution. Seems like they were not entirely aware of this happening prior to this issue being opened. Google Pay's flutter version came out over 3 months ago and is still extremely janky at launch on iOS. Similar characteristics, 1st run hella janky, 2nd run somewhat janky, 3rd run smooth.
Maybe someone from Flutter team could reach out to Nubank and Reflectly to see how they have such smooth animations. Reflectly CTO recently did an interview and they are still using Flutter for sure.

I'm super curious how Reflectly handles this for example, I've tried their app on iOS and it seems buttery smooth.

Folks let's please leave this bug focused on the actual issue that was filed and not turn it into a discussion forum for anything related to jank again...

(@aliakhtar the appropriate place for asking for help is probably our discord, see the contributing docs for details)

Folks let's please leave this bug focused on the actual issue that was filed and not turn it into a discussion forum for anything related to jank again...

Yep, I think we need a cure-all.

@masterlonghorn I quickly whipped up a barebones lib this evening to demo the pseudo splash screen approach for warming up animations (navigator animations, custom ones, whatever it just takes any widgets): https://pub.dev/packages/warmup_routine. It's not a scalable solution and should be used at your own risk. Hopefully it more just gives folks an idea of the most immediate thing that can be done to help with animations.

Flutter team did investigate archiving Metal shaders at runtime, but from what I understand this wouldn't improve the jank by much. Presumably, the main issue is that the pipline state object is being created within a frame workload. Results of this investigation can be found here https://github.com/flutter/flutter/issues/60267. Also, a separate issue to address this pipeline state creation has been created https://github.com/flutter/flutter/issues/74630.
From my experience with native iOS development, I'm most certain that UIKit animations doesn't start without everything ready in place. For example, on some rare occasions it's possible to experience a delay of more than 100ms before push segue triggers. If a warmup can be done in a reasonable time before animation begins, I believe that this would be a good solution for this problem. @Hixie suggested this solution here https://github.com/flutter/flutter/issues/74630#issuecomment-767078344

@danReynolds  That looks awesome, have you been able to try that with your project and see if it made a difference?

@Hixie What I don't understand is why Skia behaves differently on consecutive runs. I mean I understand that on first run it has to compile and cache but why does is compile again on the second run?

I think what @armandsLa mentioned is really key here. It's one of the big differences I've noticed between iOS and Android - iOS seems to delay an animation until it can render it smoothly whereas Android doesn't. If we could mimic that native functionality on iOS that feels like a very solid solution.

@danReynolds  That looks awesome, have you been able to try that with your demo project and see if it made a difference?

Yep I have it run the open container animation 3 times and then it is smooth when I test it out in the app

I was looking at this animation on my iPhone XR to see what's going on:
open_container.json.zip

@goderbauer if I understand the table correctly the first column shown the frames?
Why do we have more frames on the second opening and what are the shaders at the end of each process that take so much time?

Why do we have more frames on the second opening

I think that's because the animation always takes x milliseconds. Since for the first opening, it takes so long to produce individual frames, in total less frames are needed to cover the duration of the animation.

See https://github.com/flutter/flutter/issues/76180#issuecomment-780932827 for a discussion of why I think we are seeing additional shaders get compiled in subsequent runs of the animation.
In order to make this bug easier to follow for people working on it, I'm going to aggressively hide comments that are not directly adding new information. Please don't take offense if I hide your comments (I'm hiding some of mine too, including this one).
See https://github.com/flutter/flutter/wiki/Issue-hygiene#every-issue-should-be-actionable for details.

A video of the jank is available here:
https://photos.google.com/share/AF1QipOIN6m7QjsVUf63zeMXriQW0pg_npG3e0mwBnzV_TojsNzN4kEpXzFiKC6vVRrUzg?key=Wk96RzBNdnFTRF8xTDVkV08yRGFlZHdxMktSUWRR

Does it look like this at every opening?

A video of the jank is available here:
https://photos.google.com/share/AF1QipOIN6m7QjsVUf63zeMXriQW0pg_npG3e0mwBnzV_TojsNzN4kEpXzFiKC6vVRrUzg?key=Wk96RzBNdnFTRF8xTDVkV08yRGFlZHdxMktSUWRR

@danReynolds Does it look like this at every opening?

A video of the jank is available here:

https://photos.google.com/share/AF1QipOIN6m7QjsVUf63zeMXriQW0pg_npG3e0mwBnzV_TojsNzN4kEpXzFiKC6vVRrUzg?key=Wk96RzBNdnFTRF8xTDVkV08yRGFlZHdxMktSUWRR

@danReynolds Does it look like this at every opening?

No and this was actually a question I had, it seems to be on every fresh install or cold restart after a reboot of the device. I haven't tried so upgrades but I've heard that causes it too. Would that fall in line with how the shader caching on iOS works?

To be clear I would say that even that happening the first time is a problem.

To be clear I would say that even that happening the first time is a problem.

100%, this entire post is motivated by the problems we see on first run as it is the user's first experience with your application and that impression is critical.

Sadly I've experienced similar problems with jank on Android when using lottie files.
In general I think we lack the proper tooling in Flutter to even start to diagnose these kinds of issues.
If there was an easy way to go about investigating the root cause then we'd be able to open a PR instead of waiting on one team.

Is there any ETA or timeline for when this issue might be resolved?
Is there another issue related to this where someone has been assigned to it? This issue and others like https://github.com/flutter/flutter/issues/74630 are still unassigned.

Somebody needs to file a PR to remove the misleading messages about Flutter being jank-free. I love Flutter but it's just sad to see so many developers misled by the false promises about 60fps. It has been 10 months with little to no progress on this issue.

@Hixie Would you be able to put out a roadmap with timeline? It took only 2 days for this to reach top 10 liked issues which perhaps tells how eagerly folks are waiting for a fix. We all love Flutter (and its promises) and appreciate the work you guys are doing, but this issue prevents anybody serious from releasing to app stores. I think most of us were happy to see Google Pay adopt Flutter, but super disappointed with its janky launch performance on iOS.
This issue needs full force of the Flutter team. And a roadmap with timeline would be reassuring.

I know this is off-topic... but we need to fix this to shut these people up lol

Is there anything actionable here for someone without the experience to tackle implementing a fix?

My poor solution:
When a animation-widget with the same feature is heated, the original animation-widget is also heated.
I run all the animations(fake animation-widget) invisibly 5 times in turn.
In this process, I prefer some of the original widgets to work without any effect until the heating is complete.

Is there anything actionable here for someone without the experience to tackle implementing a fix?

Not currently. Waiting to hear back from the experts.

@joekendal Please file a bug with steps to reproduce just like this one but with lottie, so that we can investigate that separately. Thanks.

@aliakhtar Right now I'm discussing this with our colleagues on the Skia project, and @chinmaygarde is working on a design as part of https://github.com/flutter/flutter/issues/74630 that might provide a solution.

@masterlonghorn That's... not how engineering works. Sorry. This is an architectural issue, it's not something that can be trivially patched in a few hours. We're going to design solutions, test them, deploy them, but it will take some time... and there's no way to know how much time. Roadmaps and tiimelines could only be misleading.
For what it's worth, we've been studying this problem seriously for the better part of a year now (you can see some of our past efforts e.g. in https://github.com/flutter/flutter/issues/60267 and other issues), and even before that we've considered the issue of first-launch jank to be a serious one, hence our attempts to address it with shader warm-up, first manually then automatically. We've also been working closely with the GPay team to improve their performance, and we look forward to their next release (these efforts have already paid off in the Android version of GPay in the Play store, though we have not yet had a chance to deploy a new iOS version). All of this means that we have already studied a number of options and learnt much from this; the more we learn, the closer we get to a long-term sustainable solution.
What's really helpful is to have concrete cases that we can study. This bug is one of the only actionable issues with actual steps to reproduce, code that we can study, to have been filed. If you want to help, but are not a graphics expert, then the best thing you can do is create tiny, simple, sample apps like @danReynolds', showing specific cases of jank that are reproducible and that can be studied "in the lab". When we have studied jank issues, such as those in GPay, we have found that there are a multitude of causes -- some easy to solve by tweaking build methods, other (such as the one here) that highlight complicated interactions in Skia. Only by having actual test cases can we really fix these issues.
Commenting on this bug is highly unlikely to help unless you are actively working with the team to resolve this specific issue. I'm going to lock this bug to people with contributor access only to help us stay focused on the issue.

Not currently. Waiting to hear back from the experts.

Looks like performance here is slightly better but still not good.
https://github.com/flutter/flutter/issues/77301 would help determine precisely which shaders are being triggered.
https://github.com/flutter/flutter/issues/77412 is probably the long-term solution here.

Looks like performance here is slightly better but still not good.
#77301 would help determine precisely which shaders are being triggered. #77412 is probably the long-term solution here.

Hi Hixie, any update on this?

Work on 77412 continues and progress is looking good, but as noted in that issue, it's a long-term project (basically rewriting Skia) so it'll take a while. Nothing particular to report yet.

Hi @Hixie have you made any progress you can share on this ?

Significant progress on 77412 continues to be made; the experimental branch just landed into the engine repo on Friday in fact. It'll still be many more months before this work is in a stable release though. It's basically a rewrite of our graphics backend, which is definitely a non-trivial effort.

@Hixie Can you link the branch in the engine repo here? I would love to dig into it.

@Hixie Can you link the branch in the engine repo here? I would love to dig into it.

https://github.com/flutter/engine/tree/main/impeller

It was recently announced that Impeller is now included in Flutter 3.7 with initial support for iOS:
https://github.com/flutter/engine/tree/main/impeller#try-impeller-in-flutter
https://www.youtube.com/watch?v=gKrYWC_SDxQ

@chinmaygarde I think we should consider closing this issue.  The 90th percentile raster time should be an accurate measurement of jank since jank can be thought of as infrequent frames times > 1/fps.  Here is the current state of the 90th percentile raster time for the benchmark that runs through the gallery app.

The grey line is impeller and the orange line is skia (link).  Impeller has been turned on by default for iOS since 3.10.
This issue seems to be focused on iOS, so there is no need to gate it on any work for Android.  I believe the jank issue manifested more on iOS.
If we decide not to close this now I think we should come up with good exit criteria for the issue, maybe file a separate issue for Android if we want.

Yeah this is definitely fixed!
If there are similar issues please don't hesitate to file new bugs and include as much detail as possible (including ideally code to reproduce the problem, precise steps for doing so, and maybe a video showing the problem, if that is possible).


Fixed #32468 -- Used method_decorator to apply never_cache decorat…

…or on login and logout views in admin site.
Fixed 32468

@hakib Thanks :+1: What do you think about adding a check to never_cache()?, e.g.
if not isinstance(request, HttpRequest):
    raise TypeError(
        "never_cache didn't receive an HttpRequest. "
        "If you are decorating a classmethod, be sure to use "
<EMAIL_ADDRESS>    )

I'm afraid it might break code that took inspiration from Django admin... when I tried to override login on my custom admin site I used the decorator ad Django did, and I did not notice this issue until I tried to use another decorator that uses the request object.
Maybe a warning?

I'm afraid it might break code that took inspiration from Django admin... when I tried to override login on my custom admin site I used the decorator ad Django did, and I did not notice this issue until I tried to use another decorator that uses the request object.

Yes, but it will help to detect misuse of the decorator (like in your case), and fix is straightforward, so I would raise an error. I think it's acceptable.

Thanks @felixxm
Please see the amended commit.

Thanks @felixxm!
Let me know if there's anything else I can do.


[material-ui] Prop className did not match with Next.js

Steps to reproduce
I'm not a native, please bear with me.
Back Story
Back in the day without NextJS or Server Side Rendering
We thought of a way to reuse the responsive logic of a component, we decided to add the size property on every component, and change it based on the screen using useMediaQuery.

the hook useResponsive at line 9 is our custom hook based on useMediaQuery

This works well for us.
Current behavior
Currently, we try to use NextJS
And got this warning

it makes our UI always render the xs size, and only works after we try to resize the screen, you can see the demo below
https://github.com/mui/material-ui/assets/164217891/d5b6e5df-08f9-481e-9dc1-b53cdbd4bdf3
after researching, we found that we set noSsr in useMediaQuery to true, so we set it to false

we no longer see the issue, but a new problem comes, on the first time, rendering, the useMediaQuery always returns false, making our UI always render the xs size for the first 1 second, and then it renders the correct size.
we have tried all approaches from this https://github.com/vercel/next.js/issues/46605, but still not working
we are stuck here, please help, thank you so much.
Expected behavior
No more warning, the useMediaQuery should return true on first rendering
Context
No response
Your environment
I'm using the latest
Search keywords: Prop className did not match

This section of the docs may be helpful: https://mui.com/material-ui/react-use-media-query/#server-side-rendering?

thanks, I will take a look at it and tell you later

hi, it seems like the solution in  https://mui.com/material-ui/react-use-media-query/#server-side-rendering doesn't suit my expectations, I'm trying to reuse the responsive code, by encapsulating it in the component, and public the size property. do you have a best practice for reusing the responsive code?

@vupham04112002 can you provide a reproduction to see why it doesn't suit your expectations?


[Fastload Utils] Add app history functionality

WIP
@halemmerich
The app history is used to navigate back to previous apps when going back from the current app.
To do before converting PR from draft:

[ ] Run it at home for a while.
[x] remove widget draws inside timeouts.
[x] Clean up after testing.
[x] Clear the app history if the user chosen clock app is loaded? - if .bootcde is loaded history is reset.
[x] fix the situation: 1) Clock face is active, the app history isn't cleared. 2) Message arrives and auto-opens. 3) Message auto-closes. 4) The app to load is pulled from the history, when ideally the clock would be displayed again instead.

Can be loaded here in the meantime: https://thyttan.github.io/BangleApps/?q=fastload
Should this be a separate new app, does the added code contribute too much to loading times? (Not in my experience so far. No timings done)

Cool idea :+1:

removed commits that introduced setTimeout(Bangle.drawWidgets,0); in onchange functions.

How are you feeling about this now? It's been a while.
Battery usage could have been that issue with the buzz implementation?

How are you feeling about this now? It's been a while.
Battery usage could have been that issue with the buzz implementation?

I'll make a judgement sunday night :+1:

I think it's ok to merge this. I've lost about 50 % of the battery in about four days. A little much maybe, but not very bad. And I suspect message handling more then app history for slurping the juice (I don't really have any data to back this up, just a hunch).

Great, thanks!


*: add proto3 optional support

I think it would be good to start thinking on how to add support to the proto3 optional keyword.
This feature request could be addressed in two different steps:

[x] Add the required supported features parameter to the code generator response #432
[ ] Implement optional support in the library

WDYT?

Hi!
Is there any progress for this? It'd really help. Does anyone know of any workaround for this?

Just in case someone else also stumbled upon this issue: https://stackoverflow.com/a/46821842/4521547

This sounds good, but we'll need to add optional support to PGS. Blocked on lyft/protoc-gen-star/pull/85

Looks like this can go ahead now. 🎉

Checklist updated with the PR bumping to the newly released protoc-gen-star version.

I assume for this, the templates need to be updated for sure, but are there any additional checks that would need to be added?

This issue is about support for go or support for java too?

I am waiting for this support for Java

Hi all,
What is the status of this issue? Is someone working on it? When we should expect a fix for this issue?

There's been some progress (see PRs/issues linked above). It looks like #474 made some progress but needs some changes.

PGS v0.6.0 was released a few hours ago, which includes fundamental changes to progress this forward.
We're currently pending a few things in to close this out. Most notably:

[ ] updating PGS deps & fixing CI
[ ] support for *.cc, *.java & *.py
[ ] test(s)

I am planning to work on this over the weekend & see where I land.
@akonradi how feasible is it to split support for different languages into different PRs? While I'll try my best, I can't say I am overly confident with templating for some of these languages tbh.

Splitting support for different languages across multiple PRs SGTM.

Any update on this? ✌

Is there any update on this? This is preventing us from using this plugin.

Is there any update on this? This is preventing us from using this plugin.

There's a PR open, if you have any java experience and can give a hand that would help immensely :)
https://github.com/envoyproxy/protoc-gen-validate/pull/537#issuecomment-987124956

Not enough to be able to contribute :grimacing: we are only concerned with the go implementation.

Is there any update on this? This is preventing us from using this plugin.

same here

maybe i am wrong but i think there is already optional support @ElliotMJackson

optionals now no longer make the plugin produce code that doesn't compile. but there are still decisions to be made and validation features to be written. e.g. should things marked not-optional be enforced to be non-null?

Thank you for your input on adding proto3 optional support to protoc-gen-validate. I'd like to inform you that these capabilities are already available in protovalidate. As we look to the future with protovalidate, we have no intention of expanding support for proto3 optional fields in protoc-gen-validate.
I appreciate your understanding. I'll be closing the issue while keeping your suggestion in mind. If you have more questions or need assistance, feel free to reach out. Your engagement is greatly valued!


img-req-dimensions

Coverage increased (+0.001%) to 99.792% when pulling 1cde9cc4817f7562837bffb63624a82230fa08c5 on Genability:img-req-dimensions into 4306e339567348af0c6920938d9a15b671ae8b80 on htmllint:master.

not sure if you guys want rules intermingling like this


(hardware_layer) IMU

Calculate angular velocity and acceleration integrate to get positions ,angular orientation,would work for short time only. would help in stabilization. Publish msg using official Imu msg. Publish data to sensor/data/imu

imu code currently uses a PATH file for the path to navstik but now we will add udev rules to mount navstik to a fixed /dev/navstik path. (issue #26) so code needs to be refactored to use this fixed path and delete the PATH file. Similar thing has been done for arduino which is always mounted on /dev/arduino.

closed by #78 #79