English Amiga Board


Go Back   English Amiga Board > Coders > Coders. System

 
 
Thread Tools
Old 09 June 2020, 09:00   #3381
midwan
Registered User

 
Join Date: Dec 2014
Location: Gothenburg
Posts: 93
Quote:
Originally Posted by pipper View Post
[mention]midwan [/mention] I recently fixed a drag’n’drop issue with DOpus that would leave corrupted images behind:

https://github.com/mheyer32/dopus5al...b06d1212d01dd0

Maybe that’s what you’re experiencing
That sounds quite possible, thanks.
midwan is offline  
Old 09 June 2020, 11:31   #3382
PeterK
Registered User
 
Join Date: Apr 2005
Location: Hangover
Posts: 2,851
Quote:
Originally Posted by midwan View Post
- If you drag an icon on top of an open Shell window, the icon image stays there forever afterwards. Is this a known issue?
Thanks for the feedback! Yes, I've noticed something similar already when I dragged an icon onto the window frame and partially over the border that some parts of the image stay remaining there after moving the icon back into the window ..., but that did also happen without my fix for the memory leak. Edit: Hmm, no this seems to depend on my fix; I can't reproduce this issue with the original 5.82 atm.

@pipper
That's good news to hear that you are still trying to improve DOpus5 for OS 3.x. I didn't know about your github project page. Maybe you can integrate my changes with AddVSprite() and RemVSprite() into your code and compile an update together with your own improvements.

Edit: The main problem with AddBob() for the custom dragging was the wrong usage of width (pixels per line) in the VSprite structure instead of words per row, as explained in the comment of the include files. Using width in AddBob() causes P96 to call AllocBitMap() and AllocVec() with a 16 times too large sizex value. And furthermore there was never a RemBob() or RemIBob() call for custom dragging from Dopus, so all these huge useless memblocks were lost. My first attempt to fix this bug was to reduce the value of width in the VSprite structure to words/row immediately before AddBob() and then set it back to width after the call, because Dopus wants to work with width (pixels). This already reduced the memory consumption by P96 to the correct value, but the RemBob() was still missing. Unfortunately, RemBob() has no effect without a following DrawGList(), which has never happened (never reported by LibSnooper). And everything I tried with RemIBob() just caused freezes, although I used the same parameters again as in AddBob() before. Maybe, you can find a better solution with Dopus using words/row instead of width for custom dragging.

Last edited by PeterK; 09 June 2020 at 13:58.
PeterK is offline  
Old 09 June 2020, 19:23   #3383
PeterK
Registered User
 
Join Date: Apr 2005
Location: Hangover
Posts: 2,851
Removed 46.4.535: Dopus 5.83 still has some dragging bugs.
PeterK is offline  
Old 09 June 2020, 20:04   #3384
pipper
Registered User

 
Join Date: Jul 2017
Location: San Jose
Posts: 278
@PeterK Pull Requests are very welcome :-)

A quick search reveals, this is the only place where the sprite width is set:

https://github.com/mheyer32/dopus5al...routines.c#L99

Code:
drag->sprite.Width=(drag->flags&DRAGF_CUSTOM)?drag->width:word_width;
It makes a distinction between the custom drag routines and the regular ones. The regular dragging routines use word_width.
pipper is offline  
Old 09 June 2020, 21:33   #3385
PeterK
Registered User
 
Join Date: Apr 2005
Location: Hangover
Posts: 2,851
Yes, I've seen that line in the code, and the usage of width is definitely a bug, but it's strange, because nothing goes wrong with CGX4, it only causes a problem with P96. The author already mentioned these problems with P96 in the list of changes or history of Dopus in a comment from 1997 (sorry, cant find it now).

And indeed, I also made a late mistake in my patched code in Dopus 5.83, which is responsible for the sticky images of the dragged icons now, as reported by midwan. I must have introduced that bug in one of the last hours and changes before I released 5.83 here, but I'm not in the right mood to fix it today, maybe tomorrow or the next days.

It seems that you are working on 5.9x code and not on 5.82 anymore like me, right?
PeterK is offline  
Old 09 June 2020, 21:43   #3386
pipper
Registered User

 
Join Date: Jul 2017
Location: San Jose
Posts: 278
I took the code from https://sourceforge.net/projects/dopus5allamigas/ and ported it into a git repository along with all history. So yeah, this is 5.9x based.
pipper is offline  
Old 09 June 2020, 22:01   #3387
PeterK
Registered User
 
Join Date: Apr 2005
Location: Hangover
Posts: 2,851
Just found this on that sourceforce site:
https://sourceforge.net/p/dopus5allamigas/bugs/58/

The memory leak is fixed in my patch, but unfortunately I've added a new bug somewhere around RemVSprite() ...

Last edited by PeterK; 09 June 2020 at 22:06.
PeterK is offline  
Old 11 June 2020, 22:08   #3388
PeterK
Registered User
 
Join Date: Apr 2005
Location: Hangover
Posts: 2,851
Uploaded 46.4.535 and a fixed Dopus 5.83 again:

The RemVSprite() call was done too early. Now, it's called after DrawDragList(), but immediately before FreeDragInfo() is executed. I hope that fixes the bug in my patched Dopus 5.83. Please don't hesitate to report any remaining issues. Thx! No changes in the icon.library code since build 535.
PeterK is offline  
Old 11 June 2020, 22:39   #3389
pipper
Registered User

 
Join Date: Jul 2017
Location: San Jose
Posts: 278
@PeterK where do you maintain your fork of DOpus? Maybe I can steal a patch or two from there :-)
pipper is offline  
Old 12 June 2020, 11:57   #3390
PeterK
Registered User
 
Join Date: Apr 2005
Location: Hangover
Posts: 2,851
Where? At home ... ... no, in fact, I have never ever compiled the DOpus5 C source code, I don't like any dev kits. It's just an in-place assembler patch for two subroutines, but I've added some short comments in backdrop_drag.c where you have to change the code to insert AddVSprite() for the custom dragging instead of AddBob() and where RemVSprite(). And I've created my own new drag flag: DRAGF_CUSTOM_VSPRITE, bit 31.
PeterK is offline  
Old 12 June 2020, 18:05   #3391
midwan
Registered User

 
Join Date: Dec 2014
Location: Gothenburg
Posts: 93
@PeterK

This new version seems to be working as expected now! Great job, thanks!

It would be great if we could integrate these fixes in the v5.9x codebase as well.
midwan is offline  
Old 12 June 2020, 20:24   #3392
AMIGASYSTEM
Registered User
AMIGASYSTEM's Avatar
 
Join Date: Aug 2014
Location: Brindisi (Italy)
Posts: 6,411
Quote:
Originally Posted by PeterK View Post
Sorry, didn't notice your Assign from ENV: back to ENVARC:, but not sure if that is a good idea under all circumstances.

Thanks for the xadmaster.library.
Peter if in the Videos you run from FFPlay you are bothered by the GUI, in the Toltype icon add the parameter:

GUI=0

All "Play, Pause, Forward, Back" commands are available from Keyboard

On AROS 68k the Arexx commands do not work from the Icon, also to activate start to "WB" or "CLI" you have to add them in the Tooltypes
AMIGASYSTEM is offline  
Old 12 June 2020, 21:07   #3393
PeterK
Registered User
 
Join Date: Apr 2005
Location: Hangover
Posts: 2,851
Quote:
Originally Posted by midwan View Post
It would be great if we could integrate these fixes in the v5.9x codebase as well.
I'm not sure what the latest development status of v5.9x is. It seems that nothing important has happened since the release of 5.91 for OS 3.x many years ago and I don't know who is maintaining the support now. Is there still somebody working on DOpus5?

The memory leak exists in 5.91 too, which I just downloaded, although I don't want to use it. Nevertheless, it should be no problem to patch also 5.91 in the same way as I did it for 5.82.

Maybe pipper can port my fix to the latest C source and compile that, because I don't want to install a C development environment for Dopus and bother with the compiler stuff.


@AMIGASYSTEM
Yeah, it would be great to see Arexx working on Aros 68k, but whenever I tried to start RexxMast it just crashes the system. Do you know any trick to let it work. Or does it need aros.hunk.gz to be installed?
PeterK is offline  
Old 12 June 2020, 23:59   #3394
AMIGASYSTEM
Registered User
AMIGASYSTEM's Avatar
 
Join Date: Aug 2014
Location: Brindisi (Italy)
Posts: 6,411
On Aros 68k only the Arexx scripts do not work from the icon, but the Arexx port works.

To make the Arexx Port work on AROS 69k you need these files:

- RexxMast OS3.x (They all seem to be the same as OS 2.1, 3.0, 3.1, 3.5 and 3.9, but 3.9 seems to work better)
- rexxsyslib_44.2.library (seems to be equal to rexxsyslib_44.1.library OS3.9)
AMIGASYSTEM is offline  
Old 13 June 2020, 21:12   #3395
midwan
Registered User

 
Join Date: Dec 2014
Location: Gothenburg
Posts: 93
@PeterK
I think I found one more, minor glitch. This one is unrelated to DOpus, but has to do with the latest library version only.

When using 51.4.535 (TC020) + DoNoColorMapping, the icons seem to lose the "shadow" effect they had. Switching back to 51.4.533 (TC020) (with or without DoNoColorMapping) resolves this.

I'm attaching a screenshot to better demonstrate what I mean.
Attached Thumbnails
Click image for larger version

Name:	antialiasing.png
Views:	51
Size:	25.8 KB
ID:	67760  
midwan is offline  
Old 13 June 2020, 21:26   #3396
Weaselrama
Registered Voter

Weaselrama's Avatar
 
Join Date: Oct 2019
Location: Neunkirchen aP, DE
Age: 59
Posts: 573
Quote:
Originally Posted by midwan View Post
@PeterK
I think I found one more, minor glitch. This one is unrelated to DOpus, but has to do with the latest library version only.

When using 51.4.535 (TC020) + DoNoColorMapping, the icons seem to lose the "shadow" effect they had. Switching back to 51.4.533 (TC020) (with or without DoNoColorMapping) resolves this.

I'm attaching a screenshot to better demonstrate what I mean.
Yeah - when I first used the new TC020 (.531? or was it .532?) it cleaned up all the Mason and Mason-like 4.1 iconsets I use. I probably didn't notice it was a shadow effect - but it worked miracles. The drawers in that series lost their jaggedness and I was able to display them against lighter or darker backgrounds. Looking forward to the new release, Peter.
Weaselrama is offline  
Old 13 June 2020, 22:19   #3397
PeterK
Registered User
 
Join Date: Apr 2005
Location: Hangover
Posts: 2,851
Quote:
Originally Posted by midwan View Post
@PeterK
I think I found one more, minor glitch. This one is unrelated to DOpus, but has to do with the latest library version only.

When using 51.4.535 (TC020) + DoNoColorMapping, the icons seem to lose the "shadow" effect they had. Switching back to 51.4.533 (TC020) (with or without DoNoColorMapping) resolves this.

I'm attaching a screenshot to better demonstrate what I mean.
Yes, I know that, it's a side-effect of the tighter image masking, which activates full transparency against the background already for Alpha values below 60 or even 75 with HoldTCbuffer1. This is done to cut off the ugly gray borders around the dragged icons in the custom dragging mode, which otherwise can be quite thick when the alpha channel blending is very soft. The custom dragging routines are not able to handle the alpha channel, but are simply masking the images based on the background color that would normally only exist for alpha values of zero. Drag some OS4 icons with 533 and the custom dragging and you will see what I mean.

If you don't use HoldTCbuffer1 as recommended then the unselected icons will be displayed with the shadow effect only when a drawer is opened and they are drawn from TCbuffer1 one-time. Any further redrawing is done by uncompressing the unselected images again without using that buffer. And on that way I've added the transparency masking for low alpha values, because the selected image can only use that way for DOnoColorMapping and the custom dragging routines. Unfortunately, I have no information in that piece of code whether it's the 1. or the 2. image. So I decided to make the masking not too tight as long as HoldTCbuffer1 is not used.

But when HoldTCbuffer1 is enabled the unselected images should always preserve their soft alpha blending shadows, because they don't pass the same code as the selected or dragged icon images. And HoldTCbuffer1 makes loading and dragging a bit faster, too.

Never use DOnoColorMapping without enabling the custom dragging routines in DOpus5, because this option is just doing what it pretends to do. You may just see nothing during the normal mode dragging.

@Weaselrama
I think you are talking about the difference between the 020 typical simple transparency and the support of real alpha channel blending with soft borders in the TC020 version, but that's not the effect that Midwan mentions, just the opposite.

Last edited by PeterK; 13 June 2020 at 23:00.
PeterK is offline  
Old 14 June 2020, 00:03   #3398
midwan
Registered User

 
Join Date: Dec 2014
Location: Gothenburg
Posts: 93
Thanks for the detailed explanation!
midwan is offline  
Old 14 June 2020, 00:10   #3399
Weaselrama
Registered Voter

Weaselrama's Avatar
 
Join Date: Oct 2019
Location: Neunkirchen aP, DE
Age: 59
Posts: 573
Quote:
Originally Posted by PeterK View Post
@Weaselrama
I think you are talking about the difference between the 020 typical simple transparency and the support of real alpha channel blending with soft borders in the TC020 version, but that's not the effect that Midwan mentions, just the opposite.
Ok, thanks for the info.
Weaselrama is offline  
Old 14 June 2020, 00:31   #3400
pipper
Registered User

 
Join Date: Jul 2017
Location: San Jose
Posts: 278
icon.library 46.4 test versions

Quote:
Originally Posted by PeterK View Post
I'm not sure what the latest development status of v5.9x is. It seems that nothing important has happened since the release of 5.91 for OS 3.x many years ago and I don't know who is maintaining the support now. Is there still somebody working on DOpus5?

The memory leak exists in 5.91 too, which I just downloaded, although I don't want to use it. Nevertheless, it should be no problem to patch also 5.91 in the same way as I did it for 5.82.

Maybe pipper can port my fix to the latest C source and compile that, because I don't want to install a C development environment for Dopus and bother with the compiler stuff.


@AMIGASYSTEM
Yeah, it would be great to see Arexx working on Aros 68k, but whenever I tried to start RexxMast it just crashes the system. Do you know any trick to let it work. Or does it need aros.hunk.gz to be installed?

I would try that, but I don’t have a record of what your patches are (that’s why I asked about your repository).
WRT building DOpus: don’t be afraid. This is super easy, download Bebbo’s toolchain, let it build itself, download DOpus, let it built and off you go.

Last edited by pipper; 14 June 2020 at 03:48.
pipper is offline  
 


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools

Similar Threads
Thread Thread Starter Forum Replies Last Post
ClassicWB Full and icon.library 46.4 Retroplay project.ClassicWB 8 05 August 2018 14:57
WB library conflict/versions Akira support.Apps 3 22 July 2010 19:47
PNG Icon to Color Icon Converter? Leandro Jardim request.Apps 1 24 May 2010 05:39
What's the latest version of icon.library for OS3.9? NovaCoder support.Apps 3 30 June 2009 16:43
Requesting icon.library v44+... nikvest request.Other 2 16 September 2007 02:58

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +2. The time now is 03:30.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2021, vBulletin Solutions Inc.
Page generated in 0.14570 seconds with 14 queries