Welcome, Guest. Please login or register.
Amiga Kit Amiga Store Iridium Banner AMIStore App Store A1200/A600 4xIDE Interface

AuthorTopic: Layers.library V45 on the aminet  (Read 38920 times)

0 Members and 1 Guest are viewing this topic.

Offline lionstorm

Re: Layers.library V45 on the aminet
« Reply #375 on: October 06, 2014, 06:07:29 PM »
can the included rtg.library be used without the layers.library ?

thanks Thor for updating your numerous gems !
 

guest11527

  • Guest
Re: Layers.library V45 on the aminet
« Reply #376 on: October 06, 2014, 06:32:50 PM »
Quote from: lionstorm;774570
can the included rtg.library be used without the layers.library ?
Yes, but why would you?  
Quote from: lionstorm;774570
thanks Thor for updating your numerous gems !
No problem,though the gems aren't mine. These are updates of CBM codes, and Tobias' and Alex' codes.
 

Offline lionstorm

Re: Layers.library V45 on the aminet
« Reply #377 on: October 07, 2014, 10:09:30 PM »
The reason is I am trying to get Napalm to work under AOS4.1 on my A1200PPC+BVPPC. Apparently it requires rtg.library but so far the only thing I get is a guru with the provided library, and I hope your update will make to work !
 

Offline Ancalimon

Re: Layers.library V45 on the aminet
« Reply #378 on: November 19, 2014, 02:44:46 PM »
I have received my CyberStormPPC back from Stachu.

Now I'm starting to configure things. I'm having problems with numerous 0100 000c recoverable alerts while loading workbench and while copying stuff to ram. I'll try sorting it out later.

The problem here is that adding layers.library in my Blizckick * module ....  command does not seem to replace the layers.library.

Should I use loadmodule + loadresident together with blizkick to make it work?

EDIT: I fixed to alerts. It was because that I forgot to set two jumpers on A4000T to ext after replacing 3630 with CStormPPC.
« Last Edit: November 19, 2014, 03:11:14 PM by Ancalimon »
A4000T, 604e@400&060@66, 128MB+16MB+Zorram256, CVisionPPC, VLabMotion, Toccata, XSurf100&RapidRoad, Prisma Megamix

A1200, Blizzard060@50, 256MB, Blizzard IV SCSI, FastATA mk4
 

guest11527

  • Guest
Re: Layers.library V45 on the aminet
« Reply #379 on: November 19, 2014, 07:52:09 PM »
Quote from: Ancalimon;777806
I have received my CyberStormPPC back from Stachu.

Now I'm starting to configure things. I'm having problems with numerous 0100 000c recoverable alerts while loading workbench and while copying stuff to ram. I'll try sorting it out later.
Which version of layers are we talking about? Are you using P96 or Cgfx? Have you installed the LayersAntiHack or did you set the environment variable to avoid CGfx patching over layers?  As for Blitzkick, I'm sorry, I but I don't know how this program works, I can't help you there.[/QUOTE]
 

Offline Ancalimon

Re: Layers.library V45 on the aminet
« Reply #380 on: December 07, 2014, 06:06:44 AM »
Quote from: Thomas Richter;777824
Which version of layers are we talking about? Are you using P96 or Cgfx? Have you installed the LayersAntiHack or did you set the environment variable to avoid CGfx patching over layers?  As for Blitzkick, I'm sorry, I but I don't know how this program works, I can't help you there.

Sorry for missing your reply. I have already sorted it out. Now I'm trying to figure out how to benchmark layers.library. It was because I forgot to set motherboard clock jumpers to external. I use CGX4 with CVisionPPC.

By the way, what is the best way to have smart refresh Workbench windows and also Workbench backdrop?

I tried http://aminet.net/package/util/cdity/smartwin31_usr from aminet which does the job and makes solid window moving really smooth. But from time to time things get very sluggish.
(for example the tasks window of Scout moves extremely slowly if I enlarge the window large enough...)
( Or sometimes moving window slow down too much when it is passing through another windows gadgets or left&right borders. Weird. The window is suddenly moving smooth again once it passes the the borders of another window and is moving on top of that window)

Should I start smartwin after or before layers antihack?
« Last Edit: December 07, 2014, 06:16:47 AM by Ancalimon »
A4000T, 604e@400&060@66, 128MB+16MB+Zorram256, CVisionPPC, VLabMotion, Toccata, XSurf100&RapidRoad, Prisma Megamix

A1200, Blizzard060@50, 256MB, Blizzard IV SCSI, FastATA mk4
 

guest11527

  • Guest
Re: Layers.library V45 on the aminet
« Reply #381 on: December 07, 2014, 10:37:48 AM »
Quote from: Ancalimon;779177
By the way, what is the best way to have smart refresh Workbench windows and also Workbench backdrop?
The best way is not to install any patch and leave the refresh mode like the program authors intended them to be. Just to give you an idea: To refresh the shell window, the console (ViNCEd or console.device) have to redraw all the text within. If that is a smart refresh window, the graphics content had to be blitted from an off-screen buffer into the screen. Usually, the former is faster than the latter, at least on a graphics board, and it uses less memory (information for the missing text is stored in the console anyhow), so it is just best to leave things as they are, and not to "improve" them. "Smart Refresh" is for programs were redrawing would be a relatively costy operation, and this does not hold for the workbench or the console, all of which are trivial to refresh.

Solid window moves should be already pretty fast the way how layers works right now, i.e. when moving a layer around, it tries to preserve as many bits as possible on the move. The algorithm there improved from V40 as well and should be much better. No need to install any patch here.

Window enlargement works likewise. Layers tries to preserve as many bits as possible, but of course it needs to trigger refresh requests for the missing bits. If the program has lots of stuff to redraw, it will take a while. "Smart refresh" won't help here (Superbitmap would, but that requires native support from the program) since the "missing pieces" that become visible are not hidden anywhere, but were simply not present before.  
Quote from: Ancalimon;779177
Should I start smartwin after or before layers antihack?

You shouldn't start this at all.
 

Offline TuKo

Re: Layers.library V45 on the aminet
« Reply #382 on: September 17, 2017, 01:29:52 PM »
Hi Thomas,

I noticed some graphic glitches with the v45 library. The most visible is when using LimpidClock as it is easily reproducible.

I recorded that in a video :
https://youtu.be/rL4pSJo2mQw

Any chance to have a look at this ?
 

guest11527

  • Guest
Re: Layers.library V45 on the aminet
« Reply #383 on: September 17, 2017, 10:30:01 PM »
Quote from: TuKo;830730
Any chance to have a look at this ?

Sure, as soon as I have a chance to check with my Amiga. Can you provide details as how to reproduce it? Is it sufficient to install the mentioned program? I supose I can find it on Aminet?

V45 layers (has to) use some of the internal layers structures in a somewhat different way because the layer-arrangement algorithm is quite different. It's all "internal use only", but some programs may use this information anyhow.
 

guest11527

  • Guest
Re: Layers.library V45 on the aminet
« Reply #384 on: September 18, 2017, 05:32:19 PM »
Quote from: TuKo;830730
Hi Thomas,

I noticed some graphic glitches with the v45 library. The most visible is when using LimpidClock as it is easily reproducible.

Sorry, not reproducable here. You seem to have another hack installed that performs transparent window movement. I don't know how this works, but it does not seem too unlikely that this is the culprit. What exactly are you using there?
 

Offline Oldsmobile_Mike

Re: Layers.library V45 on the aminet
« Reply #385 on: September 18, 2017, 08:22:05 PM »
Quote from: TuKo;830730
I recorded that in a video :
https://youtu.be/rL4pSJo2mQw

I couldn't for the life of me figure out what is going on here.  Could you at least point the camera directly at the screen when trying to document an issue? :laughing:
Amiga 500: 2MB Chip|16MB Fast|30MHz 68030+68882|3.9|Indivision ECS|GVP A500HD+|Mechware card reader + 8GB CF|Cocolino|SCSI DVD-RAM
Amiga 2000: 2MB Chip|136MB Fast|50MHz 68060|3.9|Indivision ECS + GVP Spectrum|Mechware card reader + 8GB CF|AD516|X-Surf 100|RapidRoad|Cocolino|SCSI CD-RW
 Amiga videos and other misc. stuff at https://www.youtube.com/CompTechMike/videos
 

guest11527

  • Guest
Re: Layers.library V45 on the aminet
« Reply #386 on: September 18, 2017, 09:57:27 PM »
Quote from: Oldsmobile_Mike;830777
I couldn't for the life of me figure out what is going on here.
That is easy to spot. Apparently, the workbench misses a refresh of the backdrop layer after the front window moves away from the clock.

Now, there are two issues here: First, the system does not natively support semi-transparent or partially-transparent layers, so the clock has to fetch the background somehow. This "somehow" might be important since grabbing the contents of a window underneath requires working with layers internal structures, and in particular locking some of its structures such as nothing happens *while* the clock fetches the background. That is a potential source for the problem.

Problem number 2 is that intuition does not support full-size window movements. IOWs, whatever enables it has to interact with intution in a way that intuition did not natively support. This typically requires working on some internal structures of intuition which may fire back. In particular, the traditional window movement happens in the intuition input handler, and dependencies between this and the intuition and layers semaphores are somewhat fragile. So this is unfortunately also calling for problems.
 

Offline Georg

Re: Layers.library V45 on the aminet
« Reply #387 on: September 19, 2017, 07:42:07 AM »
Quote from: Thomas Richter;830778
Apparently, the workbench misses a refresh of the backdrop layer after the front window moves away from the clock.


No, in that area with the "trash" there is the ~non-user-visible fake-transparency LimpidClock window, not wb backdrop window. It maybe tries to auto-refresh (close/reopen
window?) the whats-behind-snapshot (initially done by opening window with LAYERS_NO_BACKFILL) at the wrong time.

Quote

Problem number 2 is that intuition does not support full-size window movements. IOWs, whatever enables it has to interact with intution in a way that intuition did not natively support. This typically requires working on some internal structures of intuition which may fire back. In particular, the traditional window movement happens in the intuition input handler, and dependencies between this and the intuition and layers semaphores are somewhat fragile. So this is unfortunately also calling for problems.


Since decades the way this was done is to detect click into titlebar in input handler or commodity and then simply move window with a normal Intuition function like MoveWindow() (best in a helper task, not in input.device task context directly to give app tasks time to refresh their simple refresh windows in between while window is dragged). No internals of Intuition touched.
 

Offline TuKo

Re: Layers.library V45 on the aminet
« Reply #388 on: September 19, 2017, 08:06:04 AM »
Hi Thomas,

I could set up a small CompactFlash image with a bare 3.9bb2 setup and MCP 1.49 (program I use to enable Solid Windows) to try to replicate the bug.

Thanks in advance for your time spent on that bug.

Would that fit ?
« Last Edit: September 19, 2017, 08:09:25 AM by TuKo »
 

guest11527

  • Guest
Re: Layers.library V45 on the aminet
« Reply #389 on: September 21, 2017, 09:19:27 PM »
Quote from: TuKo;830796
Would that fit ?

I wouldn't know where to fit the card in. (-:

Frankly, I'm trying a bit harder now to reproduce this on a clean system. In an attempt to make this simple, I wrote a small arexx program that moves a window over the clock:
Code: [Select]
/* move window test */
call addlib("rexxsupport.library",0,-30)
address WORKBENCH
do i=1 to 50
 do j=1 to 5
  movewindow window "SCSI:" leftedge 500-i*5+j*2 topedge 10+i-j
  call delay(1)
 end
end
which mimics a bit the erratic pattern in which a window overlays the clock. But without much success.  You may try to play with this as well, adjusing coordinate names and window names, of course.

I need something that is a little bit more reproducable than just moving the mouse by hand, and something that is a little bit more reliable than MCP.

The problem here is that one cannot reliably call MoveWindow() from within the intuition input handler (which is responsible for the dragging the window, receiving the move movements and performing the actual layer movement as well, actually). My best guess is that MCP plays with the rather delicate semaphore hierarchy of intuition to avoid a deadlock, but then fails to cover the interactions between all the semaphores correctly, leaving some structures unlocked that should rather be locked, hence causing a conflict somewhere.

If there would be some other form of moving the window *but* MCP, then I would have second look, but this particular program is so much known for its bug riddance and ignorance of system guidelines that I don't really want to make any speculations as where to look.