Feature Request: Improve image latency

[nex3]

One thing my draft group struggles with on dr4ft is images failing to render when a new pack is available. I've dug into this somewhat, and it looks like the heart of the issue is that all image srcs are pointing at api.scryfall.com which redirects to the true CDN URL, and these redirects can take a non-negligible amount of time up to a few seconds.

At first, I tried to mitigate this by sending the list of all possible cards (all the cards in a cube or all the cards in sets being drafted) to each player and having them pre-download those cards using new Image().src =. Unfortunately, because Scryfall uses 302 redirects from the API URLs to the CDN URLs, the redirects themselves weren't cached. The CDN images were, but those are downloaded so fast the improvement was negligible.

Next, I tried to make XHR requests to the api.scryfall.com links to cache their CDN URLs. Unfortunately, it looks like the CDN images aren't served with CORS headers, so requesting them client-side is a no-go. The API responses do have CORS headres set, but there's no way to make an XHR that doesn't follow the redirect and then choke on a CORS error.

There are a few possible options here:

• Hope Scryfall fixes the CORS headers for their CDN and use the second solution I tried.

• Make XHR requests for the full JSON info for each possible card, which will be substantially slower but will get us the information we need. Since the requests are all in the background anyway, this speed hit wouldn't be that bad unless it started overlapping with other user actions.

• Download the CDN URLs as part of building the database. This would involve using Scryfall dumps either in addition to or instead of MTGJSON dumps for the database assembly process, but it would mean no extra work would need to happen on a per-game basis to find image URLs.

• The null option: accept that images are just going to be kind of slow to appear sometimes and find other ways to mitigate that (like rendering a plain text version of the card until the image loads).

[HerveH44]

Hi @nex3 , @mixmix did some magics on card rendering with the last PR. Could you check again and let us know if it suits you as it is or if this issue is still valid ?

[mixmix]

All I did was make the text view nicer to read, and had it show in place while the images arrive. We could make further improvements to that rendering if we wanted, though it seems like a parallel solution.

Also just saw that mtgjson crew just released a new graphql api which might help? (haven't looked closely yet) https://mtgjson.com/mtggraphql/

[HerveH44]

@mixmix how could graphQL api help us? I don't know much about the technology but we only fetch data from mtgjson during import of sets, that happens only when they update to a new version. Maybe it could help us fetch less data during the transfer but I don't think it's very important. But again, maybe I am missing something.

[LotusWalker]

I think this is still a valid issue. My draft group also noticed that images render quite slowly, and we are often waiting for the images to load while we make picks. @mixmix ’s improvements to the text view have made things much better, because no even when the images haven’t yet loaded we can see what cards are available.