Linux usage
does anybody know, what is the percentage of users of BricsCAD according to platforms (Windows/linux/Mac)? Is this information available? I guess it's not, but I think it might be good PR move form BricsCAD to release these numbers. I think if these numbers were available, it would spread information about BricsCAD being multi platform. Media like to compare numbers like these and I think especially among linux media this information would spread fast.
Tom
Comments
-
I would love to know that too, but even more, I would like to know if Linux Version is really suitable for a production environment, I have tried by many means to get it, but rendering compared to Windows version of Bricscad (on the same hardware) is not quite comparable. Do not know why.0
-
Hi Felix,
I am actually using BricsCAD in production - we are small architectural firm and I am draftsman. I also use draftsight. I wanted to switch to BricsCAD with all my projects, byt some 2D files are so slow to open and regenarate in BricsCAD, that I cannot use it. I am waiting for multi threaded regeneration to work reliably to switch bigger projects to BricsCAD. I actually think BricsCAD's viewport speed is not that bad, but I admit under windows it's much better. And there are some cases which bring it to it's knees. These are the biggest drawbacks of BricsCAD under linux in my point of view. Together with the toolkit problems - there are lot of little bugs and glitches which are very annoying. Draftsight uses Qt and has none of these UI problems.
But even though I use it, I would be hesitant to use it under linux in company, where people uninterested in software would have to use it. I guess that wouldn't work right now with those small annoying bugs.
On the positive side, I think BricsCAD packs really lot of good features - almost as much as windows version. The most positive thing in my point of view is BricsCAD's developers and the whole team - it's so unlike any other commercial software, that it keeps amazing me. They react fast and try to help. I only encountered such enthusiasm in free opne sorce software, but not with commercial. So props to BricsCAD's team, I hope the will progress the software under linux fast.0 -
I'm an architect and use Bricscad for all my 2D drafting and find that it is and has been an excellent tool (with occasional hiccups.) I have also done side by side speed comparisons opening files and zooming with Autocad and have found the Bricscad was much faster, although it's not really a fair test as Bricscad was running on my desktop computer (now 7 years old) and Autocad was running on my consultants' laptop computers (2 years old or younger, both Apple and Windows, but still laptops.) Anyway, I mean to say that Linux Bricscad is certainly up to the task of my architectural practice. -- I do not know about 3D because I don't use it. -- That said, I've found the recent releases to be a little cumbersome and hope the team is working to speed things back up.0
-
In the above I wrote "speed things back up." That isn't entirely accurate. My issue with the latest software has to do mostly with keyboard issues. The speed itself is great. My drawings can get very dense and zooming is nearly instantaneous. When I have had drawings slow down, it has always been an issue rendering text.0
-
We are a small developing office in the fire prevention. We use 'Bricscad' since 5 year's on Linux ('ubuntu) and am very contented with the development. I also use in parallel 'AutoCad2008' under Windows - Bricscad works faster, performanter.
However, there are a few small problems with graphic arts (pictures) and text.0 -
Hi guys,
thanks for sharing your experience, I am glad to hear people using linux CAD in production with success.
@John: can you specify your keyboard problems? I have problems with loosing keyboard focus (or actually loosing keyboard at all - keypresses stop being recognized by BricsCAD from time to time). The only solution is always to click with mouse, than keyboard starts to work again. I didn't find any concrete reason for this behaviour - it seems random to me.
@Thoralf: true. One of my files which I work with in draftsight has lots of pictures in it. This file brings BricsCAD's to it's knees. The viewport performance gets very slow.
Did you find any workaround to your text problem? Any setting to make text rendering in viewport more simple?0 -
Hi Tom,Yes, this is the same keyboard focus problem. It only happens to me with PROMPTMENU ON. We discussed it before in this thread: https://forum.bricsys.com/discussion/25933 I did not report the bug because I assumed you already had.Unfortunately for me, with PROMPTMENU OFF, I have a different problem involving spaces typed in keyboard entry. I did report that issue and it was reproducible and is under investigation.The pop-up, context-driven promptmenu is the sort of thing I meant by "cumbersome." It's a layer of software attempting to think for me and ON or OFF, it causes trouble. -- I've used CAD since 1982 and have always found the simplest tools work best.John0
-
Oh sorry, John, I didn't recognize your name .
I agree with you - I dislike the promptmenu too. But I guess it's good for casual users. It's shame it's on by default, because most of the testing goes doesn't recognize problems with PROMPTMENU off.
One thing I dislike even more and I am surprised Brucsys is pushing this tool hard is the Quad. I don't know if it's just me, but I find choosing commands on a pop-up menu - which is hover sensitive and has different context at different times and has even sub-popups - I find this a usability nightmare. I must admit I didn't even give it a chance, because it seems so conuter productive to me even at a short glimpse. Luckily, it's easy to turn off.
Hopefully PROMPTMENU=off problems will be solved soon, so that we can use good old keyboard without distractions.0 -
I would like to share this file if anyone could test. When opening with bricscad on linux and you zoom out a couple of times (cpu usage goes to 100%) and system gets really slow. When you do the same (same hardware on windows) it works perfectly.
What is even worse to my understanding is that when you run BCad over wine on linux, it improves the "speed feel", so How emulated drivers (Wine) could work better than native openGL drivers on linux?
Thanks to all.0 -
I would like to share this file if anyone could test. When opening with bricscad on linux and you zoom out a couple of times (cpu usage goes to 100%) and system gets really slow. When you do the same (same hardware on windows) it works perfectly.
What is even worse to my understanding is that when you run BCad over wine on linux, it improves the "speed feel", so How emulated drivers (Wine) could work better than native openGL drivers on linux?
Thanks to all.
Hi Felix,
I tested your file on my machine - core i7-3770 with NVIDIA GTX 650 Ti. I can 'feel' zooming and panning being slower when all of the entities are visible in the viewport. The CPU usage of one core spikes up when panning and zooming. When one is zoomed-in on a portion of the model space (not so many entites in the viewport), it becomes much smoother. I cannot test in windows, but from my experience with autocad, it can handle bigger files with smoother viewport, than BricsCAD in linux.
Can you test if the high CPU spikes occur even in windows - that might be a clue for developers.0 -
Hi Felix - I also tested your file and zipped around in it with no problem at all and I'm using a fairly old machine. I did not make any measurements of cpu usage, but I did make a screen capture video. - I would look at your graphics card. Have you tried the drawing on a different linux machine to rule out hardware issues? I don't think it's a software issue. - The video is 6.5Mb, too big to upload here. It is an ogg vorbis file, should open automatically on a Linux machine and can be downloaded here: https://dl.dropboxusercontent.com/u/39660053/stadium.ogv -- This is my first screen capture video, so please excuse the rough edges. I will leave the file available for download for a week or two.0
-
Hi Felix,
I tested your file on my machine - core i7-3770 with NVIDIA GTX 650 Ti. I can 'feel' zooming and panning being slower when all of the entities are visible in the viewport. The CPU usage of one core spikes up when panning and zooming. When one is zoomed-in on a portion of the model space (not so many entites in the viewport), it becomes much smoother. I cannot test in windows, but from my experience with autocad, it can handle bigger files with smoother viewport, than BricsCAD in linux.
Can you test if the high CPU spikes occur even in windows - that might be a clue for developers.
Thank you very much !
Yes I have tested that on Windows 7 in the same machine and I can play zooming in and out at any speed while CPU never goes uver 30%, thats why on Win never gets hang.
Also as I already mentioned I tested the windows version of BC with the Linux Wine emulator, surprisingly It works better but still hangs.0 -
Hi Felix - I also tested your file and zipped around in it with no problem at all and I'm using a fairly old machine. I did not make any measurements of cpu usage, but I did make a screen capture video. - I would look at your graphics card. Have you tried the drawing on a different linux machine to rule out hardware issues? I don't think it's a software issue. - The video is 6.5Mb, too big to upload here. It is an ogg vorbis file, should open automatically on a Linux machine and can be downloaded here: https://dl.dropboxusercontent.com/u/39660053/stadium.ogv -- This is my first screen capture video, so please excuse the rough edges. I will leave the file available for download for a week or two.
Hi John
Thanks, I saw the video looks fine, can you try if when you have all modules visible scroll the mouse wheel to zoom in and out if it does not hang?
also can you tell what Distro / video card are you using. I have tried with AMD Radeon HD5450 , Nvidia 210, 610 , and on many Intel on laptops HP, Dell,etc. all of them with the same results.0 -
Hi Felix - I see what you mean that when the entire drawing is visible that the scroll wheel method of zooming and panning does have a delay. The problem goes away, for me, when two or less of the stadium plans are visible. I use Linux Mint DE Edition with a nvidia gf108. Have you tried the keyboad meathod of zooming?I found it interesting that the point-point zooming I do is so much faster than the scroll wheel zooming you do and figured it might have something to do with the scroll-wheel method first determining the current extent of the view and then enlarging or reducing by a preset percentage for each wheel click. I also wondered if the screen extent, with the 5 stadium plans showing, is so great that a math calculation is getting snagged. With your drawing fully zoomed out, I measured from corner to corner on the screen and got a distance of 6651611 units. I then scaled your entire drawing by 0.001 and the diagonal distance shown on the screen became 4204 units. (Both measurements are approximate.) Sure enough, zooming and panning with the scroll-wheel was much, much faster. So the problem doesn't seem to be with having roughly 65,000 graphic elements on the screen but rather having a drawing extent measured in kilometers. I know that doesn't solve your problem, but it does give us a little insight about what is causing the issue.0
-
Another test. With your drawing fully zoomed out I typed "zoom .9x" and experienced a delay. With one stadium visible I typed "zoom .9x" again and experienced no delay. The problem does seem to involve a calculation of drawing extent. I hope this information helps you and the Bricscad technical people resolve the problem.0
-
@Felix: that was the first thing that came into my mind, when I saw John's video - he's using different type of viewport movement, than I do. I almost exclusively use MMB to zoom in/out and dragging MMB to pan view. In this case, the viewport gets slower with your file when all of the entities are visible in the viewport. When using John's workflow, the zooming is instant.
@John: thanks for sharing the video. It's always interesting to see other people's workflow. I might try to use the Z command followed by W.
@John: interesting thought about the scale, this wouldn't come on my mind. In my testing, when I scaled Felix's drawing by factor of 0.001, the viewport still lagged the same. There were some really huge dimensions, so I deleted all of them, together with small details to the right side of stadiums. Only after I did this, the viewport zooming and pannig got much smoother - but thats's because the number of entities dropped to 29000. Didn't you do the same thing in your testing?
@John:
Another test. With your drawing fully zoomed out I typed "zoom .9x" and experienced a delay. With one stadium visible I typed "zoom .9x" again and experienced no delay. The problem does seem to involve a calculation of drawing extent. I hope this information helps you and the Bricscad technical people resolve the problem.
That's strange. When I tested this, I got no delay in either case. I tried with the original file, not the scaled one. I didn't even see any CPU spike in CPU usage.
It's a shame it's hard to quantify viewport speed, so we can only speak about what we see and "feel".0 -
Hi all.
I use the Linux version on a daily basis (Beta version). Just tried the Stadium drawing from Felix, I get an instant crash.
However, it loads perfectly fine using the windows version of BricsCAD in Wine.0 -
Hi Tom - Yes, in the scaled drawing I did delete the dimensions. They only looked to be a handful of objects so I didn't recount. I didn't realize they amounted to half the objects in the file. I had done a couple test zooms to see if the reduced extents improved performance before I deleted the dimensions and felt that the scale alone made a difference. I'm not going to redo the test at this time. - I can propose some solutions that would speed up the performance, but that's not the point. The tech folks should be working on this --not my issue to report, if it hasn't been.-- Linux should be able to stand up to Windows in every way and the fact that the software not only lags behind the Windows version but also the Windows version run through a Windows emulator must be embarrassing.0
-
...... The tech folks should be working on this --not my issue to report, if it hasn't been.-- Linux should be able to stand up to Windows in every way and the fact that the software not only lags behind the Windows version but also the Windows version run through a Windows emulator must be embarrassing.
You've got the point John, having to run BC on a windows emulator would be a shame, i also seems a bug in how Bricscad redraws when zooming with the mouse wheel, but somehow it does not happen on windows, It would be great to know if is there anyone of the BC Developers working on this issue. This problem is stopping me from renewing licenses.
I attached another simple drawing, do some zooming in and out / CPU usage will go to 90/100% , in this case i used BC V11 with ubuntu 12.04 i386, same results. Same draw running on BC v10 windows XP, works perfectly.0 -
I attached another simple drawing, do some zooming in and out / CPU usage will go to 90/100% , in this case i used BC V11 with ubuntu 12.04 i386, same results. Same draw running on BC v10 windows XP, works perfectly.
What about newer versions of BricsCAD (v14/v15)? We don't have Mac hardware in our company, so we can't test real life performance on that platform.
Could someone provide us with this kind of feedback.
Thanks0 -
What about newer versions of BricsCAD (v14/v15)? We don't have Mac hardware in our company, so we can't test real life performance on that platform.
Could someone provide us with this kind of feedback.
Thanks
Is not about Mac but Linux version. The problem reported is on version V15, I posted this just to show that the problem is also present in previous versions. You dont need special hardware to try linux, you could even use any computer and boot with a live CD, and install trial version of BC on the running Live CD just to test that the problem is real.
I have donde that using , Ubuntu 12.04, 14.04, Mint, and Elementary OS. 32 and 64 version.
Regards0 -
Any kind of feedback on this one? I am willing to try any advice in order to achieve windows level of performance in my linux box
Thanks0 -
Try using the keyboard commands "Z" and "P" instead of the mouse button for panning and zooming until they have the issued fixed.0
-
Any kind of feedback on this one? I am willing to try any advice in order to achieve windows level of performance in my linux box
Thanks
Hi Felix,
sorry for not returning back to you. I have a lot of work right now, so I have no time for testing. As soon as I have time, I'll take a look at that file.
I must say I am not able to get used to John's way of manipulating the viewport, I am too used to using moouse wheel to scroll and pan.
Tom0 -
You've got the point John, having to run BC on a windows emulator would be a shame, i also seems a bug in how Bricscad redraws when zooming with the mouse wheel, but somehow it does not happen on windows, It would be great to know if is there anyone of the BC Developers working on this issue. This problem is stopping me from renewing licenses.
I attached another simple drawing, do some zooming in and out / CPU usage will go to 90/100% , in this case i used BC V11 with ubuntu 12.04 i386, same results. Same draw running on BC v10 windows XP, works perfectly.
Hi Felix,
I can confirm CPU spikes and viewport slowing down on my system when panning and zooming your file "drawing1.dwg". Even when I just move the mosue cursor or try to create selection box, I can see stuttering. This is quite weird, because there doesn't seem to be much complex geometry in this file. Was the file created in any special way? I see just polylines and circles.
NOTE:
I could see little improvement in viewport performance when I scaled all of entities by scale of 0.000001 with basepoint 0,0. I can still see vieport lagging, but it's a little better than before scaling. So I guess John's theory about the overall extents of the drawing having influence on performance has some truth to it
We must give to BricsCAD developers that working on viewport performance is one of th most difficult programming tasks there is, I think. But we cannot cloes our eyes in seeing, that viewport preformance is lagging windows versions of BricsCAD.
TOm0 -
Hi,
I read down the topic and I think you're still stuck on a performance problem when zooming or paning with Bricscad on linux.
I am personnally on linkux too, ubuntu 16.04 kernel4.10 and a radeon HD5450 on one of my 2 setup.
And Radeon 5450 is the problem with the actual gfx driver (the one given with ubuntu 16.04). And there is, up to my knowledge, no replacement. le proprietary drivers : 1.catalyst doesn't work any more, and the newest GPU driver (xxxx-PRO) isn't suited for HD5450 (Cedar).
On that setup, I am kind of stuck, like the drawings.
Same computer, same drawing other gfx card works flowless...
Christophe0 -
Open Studio is an architecture office in Sweden using BricsCAD for Linux as the main tool for design, modeling and construction drawings.
Visit us at http://openstudio.se/0 -
I know this is an old thread, I'm just wondering how BricsCAD is shaping up under Linux in 2021. I'm learning to use it under Windows, but use Linux for everything else, so would make sense to swap over at some point. Any recent experiences?
0 -
@Mikael Nordvall said:
Open Studio is an architecture office in Sweden using BricsCAD for Linux as the main tool for design, modeling and construction drawings.
Visit us at http://openstudio.se/Great website, great office, great projects
0 -
@andrewhockley said:
I know this is an old thread, I'm just wondering how BricsCAD is shaping up under Linux in 2021. I'm learning to use it under Windows, but use Linux for everything else, so would make sense to swap over at some point. Any recent experiences?I use Bricscad BIM under ubuntu, I tried switching to windows Bricscad on my dual boot machine, I didn't find the difference worth running it in Windows full time since I don't know windows. As far as crashes go, they seemed to be the same, crashing when there are a lot of interferences in the model.
Cheers,
0