kostyanet
Posts: 6 |
I have just ran the FF beta on my computer with PS CS2 as host app. I would apply the default 'ceramic tile' preset on to image 1024*768 pix. But it took approx 11 minutes to calculatin result.
Which system requirements is needed there? Now I have follow configuration: Adobe Photoshop Version: 9.0.1 (9.0.1x294) Operating System: Windows XP Version: 5.1 Service Pack 2 System architecture: Intel CPU Family:15, Model:3, Stepping:4 with MMX, SSE Integer, SSE FP, SSE2, HyperThreading Physical processor count: 1 Processor speed: 2992 MHz Built-in memory: 1023 MB Free memory: 329 MB Memory available to Photoshop: 907 MB Memory used by Photoshop: 60 % Image cache levels: 8 Application folder: C:\Program Files\Adobe\Adobe Photoshop CS2\ Temporary file path: c:\Temp\ Photoshop scratch has async I/O enabled Scratch volume(s): C:\, 149,0G, 98,2G free H:\, 90,4G, 29,4G free D:\, 74,5G, 23,3G free G:\, 95,7G, 42,1G free Primary Plug-ins folder: C:\Program Files\Adobe\Adobe Photoshop CS2\Plug-Ins\ Additional Plug-ins folder: not set Installed plug-ins: ... Plug-ins that failed to load: NONE Installed TWAIN devices: NONE Videographic adapter: ATI Radeon 9600 Series AGP |
|||
Posted: June 4, 2006 2:12 pm | ||||
uberzev
![]() |
How is the speed when you run FF in stand-alone mode?
|
|||
Posted: June 4, 2006 2:16 pm | ||||
Rixx
Posts: 6 |
C:\Temp ?
I've noticed in a couple of graphics handling and twain programs, that they fail/dysfunction if the default XP temp location is changed from being inside \documents & settings\user???\... Amongst other things, the memory handling of large files/actions either freezes or gets extremely slow. It actually has something to do with Windows internal (kernal) memory multipliers and limits set there-in. In the days of 98SE and the dreaded ME, Win actually would only use/handle a maximum of 127Mb of RAM. While going back several years earlier, amongst Gate's more infamous utterances was allegedly: "No one needs more than 640k of memory..." I'd thought MS had got away from the 'control-freak' disposition with XP, but it turns out they did it again at somewhere around the 750Mb mark. I was told the actual figure, but cannot remember exactly what it is. One prays their next offering will not have another maximum ram setting based on their forcasts (which are historically wrong). Anyway - I think you'll find the restoration of the default User temp will help the system/fix the fault ... although you go back to having all the problems/junk files building-up through that user-temp set-up, instead of the superior/refined C:\temp Apparently MS have made a new better JPEG ![]() I wonder if Gates is actually the patron-saint of comedians? Cheers, Rixx "What me officer??? You must be mistaken..." |
|||
Posted: June 4, 2006 2:40 pm | ||||
kostyanet
Posts: 6 |
uberzev I have tried standalone - identical result. Very very slowly. When I was waiting until FF ends up I've check the performance monitor: available physical memory was approx 300Mb, processor was busy at 100% all time, and no activity with hard disks for paging memory I've noticed. Just pure calculations.
Rixx, do you think I came here to listen your nonsenses? Environment variables is *variables* and if some app has "fail/dysfunction" from change the variable data then that app going to toilet immediately. So if FF is one of them I ready to uninstall it asap. |
|||
Posted: June 4, 2006 9:42 pm | ||||
Vladimir Golovin
Administrator |
Kostyanet -- have you tried the speed fix I posted earlier? The current beta has a bug in SSE2 detection which blocks it from running a SSE2-optimized executable. Simply put, this fix can significantly improve the speed.
Here's the fix: http://www.filterforge.com/forum/read...=5&TID=116 |
|||
Posted: June 5, 2006 2:38 am | ||||
Vladimir Golovin
Administrator |
Just tested it on my P4 3.4GHz
(1024x768 under Photoshop, speed fix applied): The first non-antialiased pass took 1 minute. The second pass (antialiasing) took another 4 minutes. The total is 5 minutes. |
|||
Posted: June 5, 2006 2:54 am | ||||
Vladimir Golovin
Administrator |
Kostyanet, please be polite -- attitudes like this are not welcome here. |
|||
Posted: June 5, 2006 2:56 am | ||||
kostyanet
Posts: 6 |
Now I have tried that instruction - delete, copy, rename - it didn't help - very slowly anyway.
![]() |
|||
Posted: June 5, 2006 5:47 am | ||||
Vladimir Golovin
Administrator |
Are your render times comparable to what I've posted above? Your CPU is 3GHz, mine is 3.4 so our render times should be similar.
|
|||
Posted: June 5, 2006 8:34 am | ||||
kostyanet
Posts: 6 |
Hmmm, it works! Very slowy but a bit faster than formerly. Under the same condition (1024*768, RGB) it took 5 minutes for apply 'Decorative Tiles' to the image now.
I try preview... 'Enable Progressive Previews' was turned OFF like as all another options there. I've turn it ON - preview took approx 2 minutes. But when it started I just press Ctr+- (Zoom Out) for reduce preview size. When preview has done - progress bar was still working. And it was working approx 5 or 6 minutes. I think that it need to create a small window for previewing or modify math for enlarge sampling (i don't know english in this area to describe my thought). So it seems my problem is solved and I start to dig documentation for create my own filter. ![]() |
|||
Posted: June 5, 2006 9:43 am | ||||
Vladimir Golovin
Administrator |
Excellent -- glad to hear that the speed fix worked for you!
Yep, we'll probably solve this by implementing a multi-pass preview with progressive refinement -- that was on our plans but it didn't make it into this beta due to time constraints. Also, we've tweaked the priority for the thread that renders thumbnails, and hopefully this will also make things a bit faster. You can expect this in the nearest update. |
|||
Posted: June 6, 2006 5:13 am | ||||
kostyanet
Posts: 6 |
But for me it is very slowly render anyway. I'm in pre-press design and my common document format is A5 or A4 at 300 ppi (cmyk of course).
I think that people like me make an attept to render some textures to future use without launch FF each time. If each render will take 20 or 30 minutes to create nice texture it will be like workaround. ![]() |
|||
Posted: June 6, 2006 11:21 am | ||||
Vladimir Golovin
Administrator |
Not only for you, I'm certain. Procedural texture generation has never been a fast process -- just look at how long does it take to render a checkerboard texture in DarkTree. Of course, comparing Filter Forge and DarkTree isn't fair because DarkTree is a fully 3D package that produces "volumetric" procedurals, and Filter Forge is optimized for 2D, but you'll get the idea. I can also suggest to experiment on smaller sizes (~100 ppi or so), saving presets, and then applying them on a large input images. Filter Forge is resolution-independent, you just have to make sure that both small-ppi and large-ppi images have a matching aspect ratio. |
|||
Posted: June 7, 2006 4:28 am | ||||
Vladimir Golovin
Administrator |
Also, Filter Forge's performance scales very well with the number of cores/processors -- a dual-core CPU will almost double the speed. Dual cores will soon be mainstream, and quad-cores will start to appear in the next few years. So I'm rather optimistic about the future performance of Filter Forge's renderer
![]() |
|||
Posted: June 7, 2006 4:32 am | ||||
kostyanet
Posts: 6 |
"to experiment on smaller sizes (~100 ppi or so), "
Ok, it's good idea, thanks. |
|||
Posted: June 7, 2006 7:13 am |
Filter Forge has a thriving, vibrant, knowledgeable user community. Feel free to join us and have fun!
33,711 Registered Users
+18 new in 30 days!
153,531 Posts
+36 new in 30 days!
15,347 Topics
+72 new in year!
30 unregistered users.