vp.readImageBuffer does not include decorations and it should
readImageBuffer does not include decorations
Could it be updated such that decorations can be included by setting a prop that could be added to ReadImageBufferArgs?
@pmconne @markschlosseratbentley @jzbuchalski this is more direct ask of what we need that relates to https://github.com/iTwin/itwinjs-core/issues/8654
@pmconne @markschlosseratbentley @jzbuchalski this is more direct ask of what we need that relates to #8654
Do I understand correctly from both issues that you would like to be able to capture the image with decorations and at a specific size? If so, can you answer my question about why you can't just resize it yourself after capturing it?
@pmconne @markschlosseratbentley @jzbuchalski this is more direct ask of what we need that relates to #8654
Do I understand correctly from both issues that you would like to be able to capture the image with decorations and at a specific size? If so, can you answer my question about why you can't just resize it yourself after capturing it?
ofc we could, but i'm not sure its obvious when calling vp.readImageBuffer that you are excluding decorations and I havent checked if the issue that led us to lobby for the omitCanvasDecorations prop in the args for vp.readImageToCanvas (where if more than one viewport is open decorations are included, but not if only a single viewport is open) applies to this as well, but if it does that would be another reason to ensure the behavior is explicit
So im asking because it both reduces bespoke handling on our side and makes your api more clear, perhaps its mutually beneficial to accommodate
@jason-crow Thank you very much for the information and the attention to detail. If there is a way to work around this easily (app resizing after receiving the image), that would be the most practical way forward right now. Due to bandwidth / other priorities, we would also totally welcome an outside PR to add resizing behavior to the vp.readImageToCanvas (https://github.com/iTwin/itwinjs-core/issues/8654). Otherwise, we can add these issues to the backlog with the proper priority for some future work by someone on core and/or rendering.
cc @ggetz
@jason-crow Thank you very much for the information and the attention to detail. If there is a way to work around this easily (app resizing after receiving the image), that would be the most practical way forward right now. Due to bandwidth / other priorities, we would also totally welcome an outside PR to add resizing behavior to the vp.readImageToCanvas (#8654). Otherwise, we can add these issues to the backlog with the proper priority for some future work by someone on core and/or rendering.
cc @ggetz
Thanks @markschlosseratbentley I will see if we inner source this