Nadav
@nadav
Suggestion for @dwr.eth @v — consider refining the interaction on frame content rendering during its “state transitions”. Feels a lil like a modem internet slideshow right now — how can it be either dramatically faster or more fluid feeling. Maybe speed is the main thing to focus on…
4 replies
0 recast
8 reactions
Dan Romero
@dwr.eth
Agree. We haven’t really experienced fast frames yet. :)
5 replies
0 recast
29 reactions
Cassie Heart
@cassie
I beg to differ 🙂 https://frame.quilibrium.com/polls/1
2 replies
0 recast
2 reactions
Christian Montoya 🦊
@m0nt0y4
Have you played 2048???
1 reply
0 recast
1 reaction
aviral10𝕏
@aviral10x
true true
0 reply
0 recast
0 reaction
grunt.eth
@grunt.eth
What can be done about the tx queuing experience, is that handled by transaction requests from frames So people don’t need to do boosted/free mints anymore with a choke point at the frame?
0 reply
0 recast
0 reaction
derek
@derek
Is speed a frame-implementation constraint or a client-implementation constraint or both? I imagine it’s a mix and wondering if there are best practices that frame builders can follow for performance in particular.
0 reply
0 recast
0 reaction
Schmidtiest.eth 🎩
@schmidtiest.eth
Many of the frames I’ve used had to have to a reload, it’s only milli to ~1.5 seconds and I have to tap again. Thinking raw data, the reload experience makes sense, the data can only be SO big, or so I’d imagine… so the expectation would be limited to those confines? ¯\_(ツ)_/¯ Ergo: faster won’t be much?
0 reply
0 recast
1 reaction
