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
LOD for images #3684
base: main
Are you sure you want to change the base?
LOD for images #3684
Conversation
The latest updates on your projects. Learn more about Vercel for Git ↗︎
1 Ignored Deployment
|
await fetch(url, { | ||
method: 'POST', | ||
body: file, | ||
}) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
can we tweak this to perform uploads in parallel?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
if we did this in parallel it feels like that might be potentially harder on bandwidth, perhaps for certain users?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
fair! tbh for this multiplayer one we could always look at using https://developers.cloudflare.com/images/transform-images/ if we wanted to really optimize this - just upload the original, let the server handle resizing on-demand (plus optimizing for smaller file size in a way that the browser won't out of the box)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hahah, Steve and I were indeed talking about this same thing this morning (albeit with Imgix, not Cloudflare's offering). I'll pull you aside and we can chat more offline on your thoughts on this.
src: await FileHelpers.blobToDataUrl( | ||
await downsizeImage(file, size.w, size.h, { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ditto re: doing some of this down-sizing in parallel
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
hah, i have a similar concern here on parallelization with less powerful machines and large images :)
@@ -171,11 +180,15 @@ export class ImageShapeUtil extends BaseBoxShapeUtil<TLImageShape> { | |||
} | |||
|
|||
override async toSvg(shape: TLImageShape) { | |||
const asset = shape.props.assetId ? this.editor.getAsset(shape.props.assetId) : null | |||
|
|||
const zoomLevel = useValue('zoom level', () => this.editor.getZoomLevel(), [this.editor]) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
imo svg exports shouldn't depend on the editor's zoom level - we usually just assume zoom = 100% for exports
When I tried a this on a multiplayer room preview i got an error when adding an image: When I tried creating a room with an image locally and then sharing it, I got a similar error from the server |
This PR adds support for "level of detail" for image shapes. When an image is created, we create multiple versions of that image (each smaller than the last) and display the smallest image for the current zoom level.
Some thoughts here:
For shared rooms / hosted assets
For offline rooms / serialized assets
For the API
Change Type
sdk
— Changes the tldraw SDKfeature
— New feature