Rick Brewster
-
Posts
20,665 -
Joined
-
Last visited
-
Days Won
378
Posts posted by Rick Brewster
-
-
why not it be a good idea to make PAINT.NET 3.0 GIF makeable
It's like asking "why can't Microsoft Word make spreadsheets?" ... it's because it's made for writing documents. You use different software (Excel) for making spreadsheets.
Likewise, Paint.NET is for still imagery, not animation.
-
A 23MB JPEG still has to be decompressed and stored in memory, and then takes up much more than 23 MB. We store the entire image in memory along with a few extra buffers for compositing and other purposes. We do not use a foreful tiling scheme like Photoshop or The GIMP, and instead have relied on the slow transition to 64-bit to provide more virtual address space for the users who need to work with enormous images. This is a core part of Paint.NET's architecture, and it was purposefuly designed this way.
-
I already told you, I can't help you.
If you don't know how to program then this is not the forum to be asking for help in, sorry. -
Xtream_Gamer, Stop bumping the topic every 20 minutes, that's very rude. Have some patience.
-
No sorry, Paint.NET is not an animation program.
-
Yeah, I know, and agree. They're not supposed to have a disable-flag for this until the next .NET release.
-
Moved to General Discussion
Please do not post general questions in the Tutorials section, as per the guidelines posted at the top of the forum.
-
I think I've found another explanation for this problem which a few people have seen, even on high end systems.
1. We digitally sign all of our binaries with Authenticode, using a code signing certificate
2. The .NET Framework always verifies Authenticode signatures as part of its assembly (*.dll *.exe) loading process (this is something I did not know until recently)
3. Verification requires the use of a Certificate Revocation List (CRL).
4. The CRL must be updated, and in fact it has to be updated quite often. This is done by downloading a new CRL from an Internet address
5. If you have Paint.NET blocked from accessing the Internet via your firewall software, then (4) will fail, but it will take several seconds to do so, thus causing a large startup performance penalty.
I'm looking to put out an update (v2.64) that addresses this, but in the meantime you can make sure that Paint.NET is not blocked from accessing the Internet. It might take me a week or two to get v2.64 published, because of the holiday and some logistical issues we've been having with our servers.
(I was actually noticing a 5 second startup delay on some very fast, pre-release Intel hardware -- a 2.4 GHz Conroe -- that had not yet had its Internet connection set up.)
-
Haha, nice sig
-
The help file explains this ...
-
Supporting plugins for Tools is not a very good idea. The reason is that the Tools are tightly coupled to the rest of the application, and so by providing a plugin model we:
1) Must expose the internals of the entire application,
2) Have less flexibility to change implementation details,
3) Make people mad if we do refactor, redesign, or change things to increase performance in ways that break their plugins,
4) Don't necessarily have a good way to "place" the tools. Do they go at the top of the list? The bottom? What if you added a selection tool, shouldn't it go along with the other selection tools? It quickly degrades the user experience, I do not want to have the "browser toolbar flood" problem in Paint.NET (you know like those screenshots where you see someone who installed 50 toolbars in to Firefox or IE6 and it's just a disgrace).
It just doesn't really work out in the end.
-
Moved to General Coding / Programming
-
Well, one of the main points of the plugin framework is that you shouldn't be showing UI except when the framework asks you for it. This is crucial because otherwise it breaks any possibility of having automation scenarios. This may not be of concern to you for what you are trying to do, however.
Essentially, if the plugin framework is not handing you any UI context (e.g. asking for a Control or giving you an IWin32Window), then you shouldn't be showing UI. Heck we might be running you in a separate thread, or out of proc, or who knows what ... all things that don't play "nice" with UI. What if I want to start using the Paint.NET file format API in another program, like a command-line utility? Your UI will not make sense in that context.
By showing UI when you are not being asked to, you are working with a loaded gun. I'm sure you can use the global Application class to sneakily get some UI context, but things could change and in the next version it wouldn't work. Or you'll be called from some context that is incompatible with what you're doing.
Also, by doing things that the plugin framework is not to made handle, you are forcing me to break your plugin (and maybe other, "innocent" plugins too) if I ever do decide to add that capability to future version of the framework. Paint.NET v3.0 is almost guaranteed to reject your current file format plugins (not that you can't fix and recompile and republish of course).
Now, Paint.NET is not an animation program, and it doesn't make sense for me to place anything in the plugin framework to facilitate this. It would just wind up being some untestable functionality in there that may or may not be used -- always a very bad idea. Paint.NET is also poorly suited for working with icons because each layer is required to be the same size, so providing untestable-but-might-be-used-by-somebody functionality in that case is also not a good idea.
Having a "load configuration dialog" does make sense, and it will be critical to have if Paint.NET ever hopes to incorporate some form of RAW import functionality. I imagine it would work similarly to the save configuration dialog, with a LoadConfigWidget on the left and a preview pane on the right. There would also then be a LoadConfigToken so that the settings could be persisted.
The other thing I'm seeing is that you may be needing the ability to "reject" a SaveConfigToken. Right now in Paint.NET if you want to save as an image type that requires configuration, we show the configuration dialog the first time you save and then we remember the SaveConfigToken so that the next time you hit Ctrl+S we just re-use those settings. However it may be the case that the image has changed in such a way that you want to require the user to go through the configuration UI again. Does that make sense?
-
We don't know why you're trying to find the installation folder. Are you just trying to use Paint.NET, or do you need access to the program's files for some reason? Are you trying to install a plugin?
-
There should be a Paint.NET shortcut on the desktop, and in the "All Programs" list in the Start menu.
-
Moved to General Discussion
Stop posting questions like this in the Tutorials section. Thanks.
-
What kind of custom save functionality UI do you need? (screenshot?) How does it go outside the scope of the current SaveConfigWidget stuff?
The load config UI is something I'd like to do for v3.0, we just never had a file format that needed it so we couldn't have done any testing or anything.
-
Renamed from generic "Newbie question" title
Do not use generic thread titles. Imagine if everyone did this: the forum would be full of generic thread titles with no way to figure out what any thread was about.
-
Moved to General Discussion
Make sure you post in the correct forum. Guidelines are posted in the Tutorials section for a reason.
Locked
Already been asked/answered many times before.
-
Obviously my explanation was lost on you. I am not a hobby programmer.
-
The image fill will be based on this imaginary bounding rectangle.
You're still clipping to the selection area though, right?
-
Hello,
I'm finally finished!
Sorry for not posting any news for a long (long, long) time :? I'll be honest with you, i used the localization of this software as a project for my final paper in my university. And it went brilliantly... i hope
That's the main reason for not asking for your help, sorry, but i had to do this on my own. But let me thank all of those who showed interest in helping me :wink:
But maybe you can help me with something. I need to know exactly what are the final steps to making the european portuguese version available. Because I have also translated the help files. How do i make them available? Do i send them in a zip file along with the strings file to the localization manager?
Anyway, if you can help, thanks in advance.
Cheers.
Vitor, you can e-mail them to me at the e-mail address listed here, http://www.eecs.wsu.edu/paint.net/contact.html
I should be able to upload it and make it available for download within a week.
-
Well, then you need to install .NET 2.0.
You stated you only have .NET 1.1 installed.
Our full installer does not manage auto-installing .NET 2.0. You will have to refer to Microsoft's documentation if you need to auto-install that prior to installing Paint.NET.
-
Neat. This is a forum about Paint.NET though, please stay on topic.
Paint.NET very slow in opening 23MB JPEG file
in Troubleshooting & Bug Reports
Posted
Why would it take 50-60 MB of memory?
A 23MB JPEG decompresses to an enormous image. Memory usage is proportional to the number of pixels in an image, not its compressed file size. For example, for a 1000 x 1000 image, memory usage is proportional to 1000 x 1000 x number_of_layers. (Each layer has 1000x1000 pixels). For single layer images we also have a relatively large memory usage penalty, as we also have a composition and scratch buffers. So really memory usage is proportional to (width x height x (layers + 2)). Also, multiply by 4 because each pixel takes 4 bytes of memory (red, green, blue, alpha).
A 1000x1000 image takes the same amount of memory after decompression whether it was saved to disk as a low-quality 50KB JPEG or a high-quality 500KB JPEG.
A 23MB JPEG is an enormous image. That's like what, 20000x15000 or something? Enormous images take enormous amounts of memory to load, even if the JPEG codec was able to squash it to a much smaller file on disk.