-
Notifications
You must be signed in to change notification settings - Fork 263
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
A function to return the dimension of an image from its assetID #949
Comments
- Function takes the asset id as parameter - Function returns "type", "id", "name", "status", "width" "height". - Close RPTools#949
Technically the getTokenNativeWidth/Height functions did this but the problem is that they depend on values set on the token and sometimes the values don't represent the actual image dimensions. Going straight to the asset for the info is the right way IMO. |
- Function takes the asset id as parameter - Function returns "type", "id", "name", "status", "width" "height". - Close RPTools#949
I’m fine with this. But I’m thinking using the MIME type of the asset and splitting it into two fields would be easier for consumption. I don’t know what other kinds of assets might exist in the future, but MIME types seem like a good place to start. I can see text assets needing a character encoding and SVG ones needing a default scale, but knowing which properties to expect will be driven by MIME type... |
Using the MIME type would be a good idea. Too bad that the type is never set in Asset.java. The class has a field for it and a getter but no setter. It also has It appears that the name is always set so putting the name in the JSON return might be nice. |
IIRC, the AssetManager also keeps track of where the asset originally came from (repo, URL, etc) so maybe that would be good to include. I don't know that much else is tracked (like last-modified time stamp and such). It might be that the more detailed metadata has to be looked up in the Assetmanager instead of getting it from theAsset itself... |
I don't see any info beyond filename - without extension - being captured by AssetManager. The .info file in the asset cache only has the filename and creation date in it. |
- Function takes the asset id as parameter - Function returns "type", "subtype", "id", "name", "status", "width" "height". - Close RPTools#949
PR #950: I added the subtype (extension) to the properties returned. |
Agreed, plus even fixed |
A good point as well. |
I noticed getting the properties from a table gives the wrong width and height if the asset isn't loaded yet - it returns the width and height of the "loading asset" image. I suggest replacing the method "getImage" by "getImageAndWait", so the function waits until the image is fully loaded before returning its properties. Or, maybe the user could have the option to wait or not with an extra parameter? |
It does return "transferring" in the status but that puts the onus of handling the delay on the macro coder. Is there a risk using getImageAndWait() that a macro could get hung up waiting for an image that never loads? The CountDownLatch does a timeout on it? |
I don't know enough to tell if A timeout could be added to the |
I'd rather not add a timeout to Go for it. |
- Fix getAssetProperties to return the correct width and height when the asset is not loaded into the cache. - Close issue discussed in RPTools#949
Tested new change. No problems found. |
… images asynchronously This is mostly a matter of patching ImageManager into the Swing ecosystem. And wrestling with the bizarreness known as cell renderers... [async] _Technically_ breaking change, but why supporting reporting TRANSFERING_IMAGE if we're going to block and wait for a non-transfering one anyways See [RPTools#949](RPTools#949), but I disagree with the reasoning. Fight me. [async] Max our marker size; not a correct change, but enough for POC non-blocking stuff; actually this related to previous commit as well where we only block so we can get accurate dimensions. Surely we can get dimensions without having to block. In my perfect world, our "image manager" is a source of truth for all things image, with metadata such as dimensions being serialized in the campaign for immediate lookup [async] Add TODO notes about AssetPanel not really being about assets [async] Non-blocking bar icons [async] Non-blocking impersonation panel [async] Non-blocking map asset for MapPropertiesDialog [async] Update PointerTool's image observer [async] FIXUP [async] FIXUP Avoid ImageObserver [async] Avoid non-chalant redundant image requests just for dimensions [async] Now do token overlays (states/bars on the map) [async] StateListRenderer now updates the JList when an image is resolved [async] Resimplify TokenBarController to just notify the JList on update [async] Initiative renderer also keeps track of the parent list now [async] TokenPanelTreeCellRenderer now properly updates [async] BarTokenOverlay and children now support observers [async] Remove Token.getIcon() in favour of callers figuring out rendering concerns themselves; also remove other unused parts of Token [async] FIXUP Avoid ImageObserver [async] InitiativeListCellRenderer no longer blocks [async] Add TODO note on getImageAndWait() inside of Token class [async] Add asynchrony to image URL loading This afffect chat, HTML 3 frames, and HTML 5 frames. Additionally includes a fix to AssetURLConnection to set up in `connect()` - which gets called once - rather than `getInputStream()` - which can be called many times.
Is your feature request related to a problem? Please describe.
It is to my knowledge impossible to get the dimensions of an image from it's asset ID. It makes it difficult to deal with images properly, for example to display an image in a frame of proper dimensions.
Describe the solution you'd like
A function, maybe called
getAssetProperties
, to return a json holding the properties of an asset. Right now only images are assets, so the json could be something like:["type":"image", "width":300, "height", 200]
The text was updated successfully, but these errors were encountered: