Thread: [Pueblo-Users] Snap poll: PNG pong
Brought to you by:
uecasm
Menu
▾
▴
pueblo-users
|
From: Gavin L. <ue...@us...> - 2003-02-19 11:21:28
|
I've been looking into adding PNG support to Pueblo/UE, and thought this'd be a good time to stop and see what you really want. The problem: as far as I can tell, Pueblo doesn't support 'streamed' images, so it will always download the entire image before the user sees anything. The alternatives: pick one, or suggest yet another if you can think of it (I've tried to cover all bases): (1) Just forget about PNG for now. Sure, we want it, but there are other, more important things. (2) Basic load-on-complete PNG support (just like GIF and JPEG at the moment) is fine. We're not fussy. (3) We want streaming images, but we'll put up with load-on-complete for a while. (4) Don't even *THINK* about releasing a version without streaming images! |
|
From: Maxi R. <te...@ve...> - 2003-02-19 22:26:35
|
On Thu, 20 Feb 2003, Gavin Lambert wrote:
> The alternatives: pick one, or suggest yet another if you can
> think of it (I've tried to cover all bases):
>
> (2) Basic load-on-complete PNG support (just like GIF and JPEG
> at the moment) is fine. We're not fussy.
>
> (3) We want streaming images, but we'll put up with
> load-on-complete for a while.
It's hard for me to choose between those two. In all honesty, I'm so used
to load-on-complete that it doesn't upset me. Yet, what would be nice is
when we specify the size of the image in our Pueblo code, I'd like to see
space set aside for the image like in HTML, so that text doesn't suddenly
jump or jumble to scramble out of the way and make room for the pic. This
way, a user can go, "Ah... There's a picture there. I just have to wait
for it to load." To go further and let us have a temporary low-res image
to load in its place like you can do, would be nice.
+--------------+ Blahblahblah. Blahblahblah. Blahblahblah.
| | Blahblahblah. Blahblahblah. Blahblahblah.
| Low-Res | Blahblahblah. Blahblahblah. Blahblahblah.
| Image | Blahblahblah. Blahblahblah. Blahblahblah.
| or | Blahblahblah. Blahblahblah. Blahblahblah.
| Empty | Blahblahblah. Blahblahblah. Blahblahblah.
| Placeholder | Blahblahblah. Blahblahblah. Blahblahblah.
| | Blahblahblah. Blahblahblah. Blahblahblah.
+--------------+ Blahblahblah. Blahblahblah. Blahblahblah.
Blahblahblah. Blahblahblah. Blahblahblah. Blahblahblah.
Blahblahblah. Blahblahblah. Blahblahblah. Blahblahblah.
Thoughts on this?
--
@}>-`--,-- @}>-`--,-- @}>-`--,-- {{@}} --,--'-<{@ --,--'-<{@ --,--'-<{@
Maxi Rose Ghost of a Texas Lady | Anime: FY, MB, KOR | Bab5, Goth
Maxi the Southern Dragon (UDIC) | Anthropomorphics, Bisexuality
http://www.vex.net/~teleute | Yaoi, Seme, LARP, Videogames
|
|
From: Gavin L. <ue...@us...> - 2003-02-23 20:04:33
|
At 17:26 19/02/2003 -0500, Maxi Rose wrote: > >It's hard for me to choose between those two. In all honesty, I'm >so used to load-on-complete that it doesn't upset me. Yet, what >would be nice is when we specify the size of the image in our >Pueblo code, I'd like to see space set aside for the image like >in HTML, so that text doesn't suddenly jump or jumble to scramble >out of the way and make room for the pic. This way, a user can >go, "Ah... There's a picture there. I just have to wait for it to >load." To go further and let us have a temporary low-res image >to load in its place like you can do, would be nice. Well, according to both the code and my own tests Pueblo does in fact create a placeholder space in the output window. If you specify both of WIDTH and HEIGHT then it will be that size, otherwise it will be 8x8 pixels. Presently only an empty space is left -- there is no border or anything else visible until the image loads. In fact, that is the only function of the WIDTH and HEIGHT attributes, since Pueblo performs no image scaling, and always displays images at their proper dimensions regardless of the WIDTH and HEIGHT specified. I could change this if people think that it's a bug... though I'd rather not, since there are caching issues involved too -- in a single Pueblo session, all images that have the EXACT same URL are linked together so that they are all the same size and will animate simultaneously. Saves memory and download time. In any case, I've added a more visible placeholder (and even made it change appearance to indicate a broken or otherwise undisplayable image) to the development code, so you'll see that in action in the next release :) |
|
From: Gavin L. <ue...@us...> - 2003-02-23 20:20:05
|
Mere moments ago, I wrote: >In any case, I've added a more visible placeholder (and even made >it change appearance to indicate a broken or otherwise >undisplayable image) to the development code, so you'll see that >in action in the next release :) Oh, I forgot to add that at the moment the placeholder doesn't support display of ALT text while it's loading, but I plan to add that in a future release. So you can add the text now, if you like, and it will show up eventually :) I have no plans at the moment to support the LOWSRC attribute (though I don't think it would be *too* difficult to do), mainly because in the end I think it just slows down display of the final image (and I haven't seen a website in the past three years that uses it). I'm open to persuasion, however ;) |
|
From: Matthew 'F. D. <fr...@sh...> - 2003-02-24 08:34:46
|
On Mon, 24 Feb 2003, Gavin Lambert wrote: >Oh, I forgot to add that at the moment the placeholder doesn't >support display of ALT text while it's loading, but I plan to add >that in a future release. So you can add the text now, if you >like, and it will show up eventually :) Excellent! Thank you! >I have no plans at the moment to support the LOWSRC attribute >(though I don't think it would be *too* difficult to do), mainly >because in the end I think it just slows down display of the final >image (and I haven't seen a website in the past three years that >uses it). I'm open to persuasion, however ;) Personally, I think that LOWSRC is a waste, especially in a situation such as a MUVE with Pueblo. Most images used in worlds are not going to be 300k monstrocities, due to the nature of the environment anyway. LOWSRC will just slow things down. Besides, isn't that what xch_prob is meant for? Sincerely, Matt @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ Matthew Duhan fr...@sh... http://www.fringenet.net When I want my opinions I'll ask me for them. WWW, HTML, VR, MOO, HRSFA, TMBG, DNA--any more initials and I'll go insane If "if" statements had no "then" clauses, |
|
From: Matthew 'F. D. <fr...@sh...> - 2003-02-24 08:23:20
|
On Mon, 24 Feb 2003, Gavin Lambert wrote: >At 17:26 19/02/2003 -0500, Maxi Rose wrote: > >It's hard for me to choose between those two. In all honesty, >I'm > >so used to load-on-complete that it doesn't upset me. Yet, what > >would be nice is when we specify the size of the image in our > >Pueblo code, I'd like to see space set aside for the image like > >in HTML, so that text doesn't suddenly jump or jumble to >scramble > >out of the way and make room for the pic. This way, a user can > >go, "Ah... There's a picture there. I just have to wait for it >to > >load." To go further and let us have a temporary low-res image > >to load in its place like you can do, would be nice. > >Well, according to both the code and my own tests Pueblo does in >fact create a placeholder space in the output window. If you >specify both of WIDTH and HEIGHT then it will be that size, >otherwise it will be 8x8 pixels. Presently only an empty space is >left -- there is no border or anything else visible until the >image loads. > >In fact, that is the only function of the WIDTH and HEIGHT >attributes, since Pueblo performs no image scaling, and always >displays images at their proper dimensions regardless of the WIDTH >and HEIGHT specified. I could change this if people think that >it's a bug... though I'd rather not, since there are caching >issues involved too -- in a single Pueblo session, all images that >have the EXACT same URL are linked together so that they are all >the same size and will animate simultaneously. Saves memory and >download time. Yes, please correct this behavior if possible! For one thing, it would be nice to have images appear at their correct size if a WIDTH and HEIGHT isn't specified. It's often overlooked or sometimes people don't know both the width and height of an external image link. 8x8 is way too small for a default image size if only one is set. As an addendum to this, I don't think that Pueblo currently supports a percentage width or height, and specifying one will cause the image to default to 8x8, which is not ideal (I could be wrong about this. It's been a while since I tested this in Pueblo.). It would be great if I could have a custom graphic divider that I can set to a percentage width, and have it work if the user resizes their window as in a browser. This may be related to the caching issue mentioned, though. As for all instances of the same image being the same size, while I understand why this was done for caching and memory reasons, I hope that it can be corrected. Computers nowadays have more memory and processor power, so hopefully it won't interfere. Perhaps cache all instances of an image with not only the same URL, but the same WIDTH and HEIGHT attributes set. This way, some caching will occur, but I can have a standard graphic that I can resize as necessary depending on the world parameters, without having to have multiple separate versions of the image based on size alone, as I do now. Just my thoughts. >In any case, I've added a more visible placeholder (and even made >it change appearance to indicate a broken or otherwise >undisplayable image) to the development code, so you'll see that >in action in the next release :) Great! Thank you. I look forward to seeing that. Sincerely, Matt @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ Matthew Duhan fr...@sh... http://www.fringenet.net When I want my opinions I'll ask me for them. WWW, HTML, VR, MOO, HRSFA, TMBG, DNA--any more initials and I'll go insane If "if" statements had no "then" clauses, |
|
From: Gavin L. <ue...@us...> - 2003-02-25 06:57:43
|
At 03:15 24/02/2003 -0500, Matthew 'Fringe' Duhan wrote: > >Yes, please correct this behavior if possible! > >For one thing, it would be nice to have images appear at their >correct size if a WIDTH and HEIGHT isn't specified. It's often >overlooked or sometimes people don't know both the width and >height of an external image link. 8x8 is way too small for a >default image size if only one is set. I think you might have missed my point. If you don't specify the WIDTH and HEIGHT, the *placeholder* will be 8x8; once the image has actually loaded, it will display at its proper size, regardless. >As for all instances of the same image being the same size, while >I understand why this was done for caching and memory reasons, I >hope that it can be corrected. Computers nowadays have more memory >and processor power, so hopefully it won't interfere. Perhaps cache >all instances of an image with not only the same URL, but the same >WIDTH and HEIGHT attributes set. Actually there's probably no need to go to that extreme; the existing caching is probably sufficient, it would just need to be modified to pay attention to the specified width and height once the image has actually loaded, and scale accordingly. So I take it that nobody is relying on the existing behaviour..? |
|
From: Matthew 'F. D. <fr...@sh...> - 2003-02-26 05:53:22
|
On Tue, 25 Feb 2003, Gavin Lambert wrote: >At 03:15 24/02/2003 -0500, Matthew 'Fringe' Duhan wrote: > >For one thing, it would be nice to have images appear at their > >correct size if a WIDTH and HEIGHT isn't specified. It's often > >overlooked or sometimes people don't know both the width and > >height of an external image link. 8x8 is way too small for a > >default image size if only one is set. > >I think you might have missed my point. If you don't specify the >WIDTH and HEIGHT, the *placeholder* will be 8x8; once the image >has actually loaded, it will display at its proper size, >regardless. OK, I misunderstood. Looks like I'll have to fire up Pueblo again and test this. > > >As for all instances of the same image being the same size, >while I understand why this was done for caching and memory reasons, I >hope that it can be corrected. Computers nowadays have more >memory and processor power, so hopefully it won't interfere. Perhaps >cache all instances of an image with not only the same URL, but the >same WIDTH and HEIGHT attributes set. > >Actually there's probably no need to go to that extreme; the >existing caching is probably sufficient, it would just need to be >modified to pay attention to the specified width and height once >the image has actually loaded, and scale accordingly. > >So I take it that nobody is relying on the existing behaviour..? I'm aware (for the most part) of the existing behavior. However, I try to write proper HTML according to the W3C spec, including at the very least width, height, and alt attributes in images. This should at least work with Pueblo, even if the behavior is not 100%. I'd rather not workaround, instead waiting for Pueblo to catch up to the spec. :) Sincerely, Matt @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ Matthew Duhan fr...@sh... http://www.fringenet.net When I want my opinions I'll ask me for them. WWW, HTML, VR, MOO, HRSFA, TMBG, DNA--any more initials and I'll go insane Didn't kill me. Wasn't "made stronger". Lawsuit? |
Thanks for helping keep SourceForge clean.
X