Hyperion Entertainment Message Boards

saimo wrote: What I'd like to present here is these two problems:
1. ConClip doesn't work anymore (nothing gets selected/copied; tested both with the native handler and KingCON);
2. make (the version included in the latest public SDK) is affected by a delay of 1-2 seconds every time it recurses into a subdirectory.

Regarding the second problem, f.ex., if a makefile has:

$(MAKE) -C directory0
$(MAKE) -C directory1

the execution is halted for 1-2 seconds between the return from directory0 and the entering of directory1. Sometimes the pause happens right after make prints the "leaving directory..." message; sometimes just before printing it.

Good luck with the hunt...

1.I can't reproduce the first problem here on my SAM Flex. I have KCON: mounted but not as a replacement for CON:. I do not have KRAW: mounted at all. No problem highlighting and copying from Multiview.

2. I tried compiling a program that recurses with MAKE -C and there was no delay. However, the program had already been compiled so I just got a fast sequence of entering and leaving directory messages.

tonyw wrote:You can't mark and copy from Multiview, yet you can from Notepad ???

Why, are they related? From the outside, it looks like they're based on totally different components (maybe NotePad uses texteditor.gadget?). The tests I report below seem to confirm this.

If that's so, then you must have an unusual system configuration. I can assure you that it works properly in a clean Update N environment (0 <= N <= 5). Somehow you have stopped it from working by removing or installing something.

I suggest that you re-install the system to a clean partition, bring up a clean Update 5 installation and check that it works as it should. Then start making your customising changes until you discover what has killed it.

I went for something more effective.

1. Firstly, I've disabled all the stuff launched by WBStartup: nothing changed, so I made a radical test...
2. I've booted without startup-sequence: the text could be highlighted and copied and pasted in the shell itself, also without ConClip running (I had memories that if ConClip was not running, the whole select-copy-paste functionality would be disabled, but I was evidently wrong; it's clear to me now that ConClip only connects the console to the clipboards - as the name suggests, after all; this also means that initially I should not have mentioned ConClip at all).
3. I have disabled quite some stuff from startup-sequence and booted normally: this time, C&P worked.
4. I started re-enabling the stuff in the startup-sequence in small bunches, making tests every time, until I finally identified the problematic line: IPrefs.
5. I removed some preference files from ENVARC:Sys/ and rebooted: C&P worked fine.
6. I started re-adding the preference files in bunches, until only one was left out, the culprit I was suspecting since the beginning: GUI.prefs.
7. I started the GUI preferences and went immediately to the Control section. After few seconds of fiddling with the flags, the problem came out: it was the Force smart refresh option - with that off, C&P works.

Starting point for the bug hunt identified

Note about MultiView: marking text didn't work in any of the configurations tried above. Just to see if it was a more general problem, I've tried with a picture, and that worked without problems.

2. I tried compiling a program that recurses with MAKE -C and there was no delay. However, the program had already been compiled so I just got a fast sequence of entering and leaving directory messages.

This is exactly how it used to (and should) be here. Thanks for reporting.

..
6. I started re-adding the preference files in bunches, until only one was left out, the culprit I was suspecting since the beginning: GUI.prefs.
7. I started the GUI preferences and went immediately to the Control section. After few seconds of fiddling with the flags, the problem came out: it was the Force smart refresh option - with that off, C&P works.
..

I can confirm here with my A1-XE and default GUI prefs enabling 'Force smart refresh' produces such behaviour can't mark&copy on Shell. On my beta system no problems. Will try to create a new GUI prefs from scratch and see what happens.

@Saimo:

You've highlighted a behaviour that is apparently deliberate from way back in the old days - if you specify Smart Refresh, then Intuition is supposed to handle the refresh (redraw) of the text and the application ignores it. The failure to show highlighted text is a side effect of that.

I've never really understood what is the benefit of Smart Refresh: selecting it never seemed to make any material difference that I could see. Why are you using Smart Refresh? Does it make a beneficial difference for you?

javierdlr wrote:I can confirm here with my A1-XE and default GUI prefs enabling 'Force smart refresh' produces such behaviour can't mark&copy on Shell.

Good to have a confirmation...

On my beta system no problems.

... even better that the problem has already been fixed

tonyw wrote:You've highlighted a behaviour that is apparently deliberate from way back in the old days - if you specify Smart Refresh, then Intuition is supposed to handle the refresh (redraw) of the text and the application ignores it. The failure to show highlighted text is a side effect of that.

I have to disagree - to me, it's a misbehaviour for 4 reasons:
1. if Intuition is supposed to be in charge of the graphic refresh, it should never fail to do it when needed;
2. the option worked ever since and now it doesn't anymore;
3. the graphical problem should not affect functionality (i.e. copying still should have worked);
4. the fact that the problem doesn't appear on the current beta system (see post by javierdlr above).

Maybe some properly updated component(s) did not make it to the release package?

I've never really understood what is the benefit of Smart Refresh: selecting it never seemed to make any material difference that I could see. Why are you using Smart Refresh? Does it make a beneficial difference for you?

I don't have access to the sources of Intuition and, except for few basic notions, I don't even know AmigaOS from a programming POV, but, from the outside, my guess is this:
* if it's up to the application to preserve the graphics integrity, then it will perform all the graphic operations (which may be many and complex, especially in these days of eye-candiful looks) every single time, even when only a small area would actually need to be refreshed (f.ex., think of a corner of a window being removed from the front of the application window);
* on the other hand, if it's the OS that takes care of the refresh, updating the "corrupt" areas is just a matter of blitting the correct graphics (the additional cost is that a copy of the application window has to be made after a refresh).
Now, I don't know how smart the implementation is, I don't know if windows are buffered anyway (thus eliminating the additional cost of preserving the graphics) and I don't know if composition indirectly plays a role here (f.ex., it might enforce windows buffers and/or make the "maintenance" redrawing operations totally unnecessary), so my uneducated guess might be wrong, but I'd say that the smart refresh is advantageous in most of the cases (there wouldn't be an option for it, otherwise).
Massimo could probably tell us a lot about this

If it made any difference to me until now I can't say, having never used the OS without that option: now that I'm forced to go for the normal refresh (I use the shell massively), maybe I'll notice the difference.

SmartRefresh means that Intuition keeps a copy of the window contents, and blits back damaged areas.
SimpleRefresh means the application has to redraw damaged areas itself.
If this is a newly-drawn area then it should make no difference whether the window is Smart- or SimpleRefresh

If Compositing is enabled, than SimpleRefresh windows behave like SmartRefresh ones anyway.

chris wrote:SmartRefresh means that Intuition keeps a copy of the window contents, and blits back damaged areas.
SimpleRefresh means the application has to redraw damaged areas itself.
If this is a newly-drawn area then it should make no difference whether the window is Smart- or SimpleRefresh

Glad to hear my guesses were correct...

If Compositing is enabled, than SimpleRefresh windows behave like SmartRefresh ones anyway.

... and double glad to know that not only I guessed this as well, but also that I don't need the smart refresh option to be on
Thanks.

Since the behaviour isn't exactly the same (otherwise smart refresh wouldn't cause troubles), evidently there are two parts of the system that (partially) implement the same thing: maybe that's where the problem lies? Anyway, this is one more reason to keep only one active.
The obvious question then is: why isn't smart refresh automatically disabled when compositing is on?

Finally, one more question: I've been talking of the option in the Controls Subsystem of the GUI preferences program, but what about the same option in the Options Subsystem? What's the difference? Is it useless with compositing enabled?
(BTW, it's always been on here, and I don't have problems. I'll turn it off and try to see if it makes any difference.)

saimo wrote:

If Compositing is enabled, than SimpleRefresh windows behave like SmartRefresh ones anyway.

... and double glad to know that not only I guessed this as well, but also that I don't need the smart refresh option to be on
Thanks.

Since the behaviour isn't exactly the same (otherwise smart refresh wouldn't cause troubles), evidently there are two parts of the system that (partially) implement the same thing: maybe that's where the problem lies? Anyway, this is one more reason to keep only one active.

Yes, there is some slight difference, but from an application's POV, smart refresh and simple refresh+compositing are the same (the application is not required nor notified to redraw damaged areas). How different they are internally is something only the OS4 devs can answer.

Finally, one more question: I've been talking of the option in the Controls Subsystem of the GUI preferences program, but what about the same option in the Options Subsystem? What's the difference? Is it useless with compositing enabled?
(BTW, it's always been on here, and I don't have problems. I'll turn it off and try to see if it makes any difference.)

The Options one is the default state for newly-created windows. I suspect selecting "Simple" here would break quite a lot of things (if compositing is off, anyway). Seems a bit strange to have this as an option.

The Controls one overrides any window that is created as SimpleRefresh and makes it SmartRefresh instead. This is possibly a good idea if you have gfx memory to burn (and, again, makes no difference if compositing is enabled on all screens)