Opened 14 years ago

Closed 11 years ago

Last modified 11 years ago

#257 closed bug (fixed)

[Expander] first launch

Reported by: diver Owned by: axeld
Priority: normal Milestone: R1
Component: Servers/registrar Version:
Keywords: Cc:
Blocked By: Blocking:
Has a Patch: no Platform: All

Description (last modified by stippi)

OK, i'll try to explain. I have customized bootscript with uncommented tracker. When haiku starts it loads tracker which in turn open /boot/beos/apps. Now, if i start BitmapDrawing -> Alt+w -> Expander -> Alt+w i could see slowness of repainting background (about a second). I don't start any other apps before this to reproduce it.

Tested with rev16575 under vmware.

Change History (18)

comment:1 by diver, 14 years ago

Summary: BitmapDrawing->Expander[Expander] first launch

comment:2 by diver, 14 years ago

Cc: korli@… added

comment:3 by diver, 14 years ago

Correction. Don't need to go through those steps written above. There is an easy way. Just start Expander after tracker and close it and you'll see slow background repainting. Maybe Expander tries to wright settings to disk, but under vmware it takes to long? Need to test it under native installation.

comment:4 by axeld, 13 years ago

Owner: changed from bpmagic@… to axeld

comment:5 by korli, 13 years ago

Is it still valid ?

comment:6 by diver, 13 years ago

I will retest it ASAP.

comment:7 by axeld, 13 years ago

And?

comment:8 by diver, 13 years ago

(In reply to comment #4)

And?

And it still valid in hrev17797 :-)

comment:9 by info@…, 13 years ago

Expander write 2 files upon being closed or window-moved:

/boot/home/config/settings/Expander_settings and: /boot/home/config/settings/beos_mime/application/x-vnd.haiku-expander

Specifically, the delay is caused by the MIME type being written.

Is this normal behaviour?

comment:10 by diver, 12 years ago

Platform: All

Can't reproduce it anymore, it's been probably fixed in meantime.

comment:11 by stippi, 12 years ago

Description: modified (diff)
Resolution: fixed
Status: newclosed

comment:12 by diver, 11 years ago

Resolution: fixed
Status: closedreopened

I can reproduce it again on first launch. BTW, the same thing happens on mediaplayer's first launch. So i think it MIME type write related which causing this delays. Reopening...

comment:13 by axeld, 11 years ago

This might have been fixed with hrev25719, please check.

comment:14 by diver, 11 years ago

I think this could even be fixed in hrev25309, where Ingo added

mimeset -apps -f /boot/beos/apps

mimeset -apps -f /boot/beos/preferences

So now both Expander and MediaPlayer should write their supported MIME types at first boot, regardless of whether you'll launch them of not, right?

comment:15 by diver, 11 years ago

Component: - GeneralServers/registrar

Yes, it's seems "fixed". But I think hrev25309 could've been hide this bug and could potentially lead to boot time increase due to a slow MIME type write as stated above. What do you guys think?

comment:16 by stippi, 11 years ago

Resolution: fixed
Status: reopenedclosed

That only happens once at the very first boot. I think the general idea behind that is ok. The other option would be to make the build system do this, but think the current solution is more fool proof.

comment:17 by diver, 11 years ago

+1 to the idea to make the build system take care of this as this will also speed up haiku start up in vmware and also potentially LiveCD boot time. Should I add a new ticket so we don't forget about it, Ingo?

in reply to:  17 comment:18 by bonefish, 11 years ago

Replying to diver:

+1 to the idea to make the build system take care of this as this will also speed up haiku start up in vmware and also potentially LiveCD boot time. Should I add a new ticket so we don't forget about it, Ingo?

Please don't; I don't think I'll implement it. The build system can't really prepare the MIME entries for optional packages, so the on-first-boot mechanism is needed anyway.

Note: See TracTickets for help on using tickets.